This document specifies HTTP/404, an extension to HTTP formalizing deterministic negative acknowledgement and resource nonexistence for distributed systems.
Internet-Draft HTTP/404 Protocol July 2025
Intended status: Experimental
Expires: January 2026
Hypertext Transfer Protocol 404 (HTTP/404)
Negative Acknowledgement Protocol
Abstract
This document specifies HTTP/404, an extension to the Hypertext Transfer
Protocol (HTTP) designed to formalize negative response semantics. HTTP/404
defines a deterministic approach for resource nonexistence, uniform
negative acknowledgement, and the denial of resource presence in HTTP-based
systems. This protocol extension enables explicit, consistent handling of
absent, unreachable, or unimplemented resources.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire in January 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
1. Introduction ............................................. 2
1.1 Motivation and Use Cases ............................. 3
2. Terminology .............................................. 4
3. Protocol Overview ........................................ 5
4. Response Semantics ....................................... 6
5. HTTP/404 Headers ......................................... 7
6. Implementation Considerations ............................ 9
7. Security Considerations ................................. 10
8. IANA Considerations ..................................... 11
9. References .............................................. 12
Appendix A. Acknowledgments ................................ 13
Author's Address ........................................... 14
1. Introduction
The Hypertext Transfer Protocol (HTTP) [RFC7230][RFC9110] provides a
general-purpose framework for distributed, collaborative, hypermedia
information systems. Existing HTTP status codes, notably 404 (Not Found),
are used to indicate the absence of a requested resource. However, there
is no formalized, protocol-level mechanism to provide deterministic,
consistent, and universal negative acknowledgements across all endpoints,
methods, and resource states.
HTTP/404 defines a protocol extension in which servers consistently
respond to all HTTP requests with a negative acknowledgement. This
approach enables the explicit declaration of resource nonexistence,
denial, or unreachability, thereby facilitating uniform error handling
in distributed applications.
1.1 Motivation and Use Cases
While HTTP status code 404 is widely implemented, its use is limited to
individual responses and does not standardize an operational mode for
universal resource denial. In practice, servers and services may require
a deterministic and protocol-level method for always returning a negative
acknowledgement to any HTTP request, regardless of resource state,
endpoint, or method.
The formalization of a negative acknowledgement protocol has multiple
motivations and use cases:
- **Privacy and Anti-Fingerprinting:**
Uniformly denying all resource requests reduces the risk of
information leakage, resource enumeration, or fingerprinting
attacks. [RFC6973], [RFC7624]
- **Honeypots and Decoy Infrastructure:**
Security researchers and operators of decoy services may wish to
present a consistent negative surface, obscuring which resources,
if any, are valid. [RFC5357]
- **Operational Maintenance and Sandbox Modes:**
During certain maintenance or compliance scenarios, operators may
need to place an HTTP service into a "deny-all" state, preventing
accidental disclosure of data or endpoints.
- **Testing and Compliance:**
Developers can use HTTP/404-compliant endpoints to test client-side
error handling, fallback logic, and negative response processing.
This protocol is distinct from the HTTP 404 status code, as it defines
explicit protocol semantics for universal negative acknowledgement,
enabling new operational modes and consistent deployment patterns.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
For the purposes of this specification:
Resource: Any identifier, URI, or endpoint requested by a client.
Client: An entity initiating a request using HTTP/404.
Server: An entity responding to a request using HTTP/404.
3. Protocol Overview
HTTP/404 extends HTTP/1.1 [RFC7230] and HTTP/2 [RFC9113] by mandating
negative acknowledgement for all resource requests, regardless of the
request method, resource identifier, or context.
A server implementing HTTP/404 MUST respond to every HTTP request with a
404 Not Found status code, even if the resource exists or would otherwise
be accessible under conventional HTTP operation.
Example:
Client Request:
GET /example/resource HTTP/404
Server Response:
HTTP/1.1 404 Not Found
X-Protocol-Denial: HTTP/404
Retry-After: never
4. Response Semantics
Servers implementing HTTP/404 MUST respond to all HTTP methods
(including but not limited to GET, POST, PUT, DELETE, OPTIONS, HEAD,
PATCH, CONNECT, TRACE) with a status code of 404 (Not Found).
The following headers MUST be included in every response:
X-Protocol-Denial: HTTP/404
Retry-After: never
The following headers MAY be included for diagnostic or informational
purposes:
X-Server-Confidence: 0%
X-Previous-Existence: Unverifiable
X-Reality-Integrity: Inapplicable
The response body SHOULD be empty. If present, it MUST NOT provide any
information about the requested resource.
5. HTTP/404 Headers
The following HTTP header fields are defined for use with HTTP/404:
- X-Protocol-Denial: Indicates compliance with HTTP/404 (REQUIRED).
- Retry-After: Indicates that retrying is not applicable (REQUIRED).
- X-Server-Confidence: Indicates server certainty (OPTIONAL).
- X-Previous-Existence: Indicates prior resource existence (OPTIONAL).
- X-Reality-Integrity: Indicates protocol context (OPTIONAL).
All other headers are ignored.
6. Implementation Considerations
Servers:
- MUST respond to every HTTP request with status code 404 (Not Found).
- MUST include the required headers as defined in Section 5.
- MUST NOT disclose any information about resource existence.
- SHOULD apply protocol behavior at all endpoints and subresources.
- SHOULD deny all content negotiation and directory listing.
- MAY log requests, but MUST NOT indicate resource presence in logs.
Clients:
- SHOULD NOT retry failed requests.
- SHOULD NOT cache HTTP/404 responses for future use.
- SHOULD NOT generate alerts for resource nonexistence under HTTP/404.
7. Security Considerations
HTTP/404 mitigates information disclosure by providing a uniform
negative response to all requests. This prevents inference of resource
existence, state, or availability from HTTP response behavior.
Operators should be aware that HTTP/404 may obscure operational
incidents, unauthorized access, or misconfiguration, as all requests
will appear identically denied.
No additional security risks are introduced by this protocol extension.
8. IANA Considerations
This document requires no IANA actions. No new HTTP status codes,
header fields, or media types are registered.
9. References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels,"
BCP 14, RFC 2119, March 1997.
[RFC5357] H. R. van As, A. Morton, "A Two-Way Active Measurement Protocol (TWAMP)," RFC 5357, October 2008.
[RFC6973] A. Cooper, et al., "Privacy Considerations for Internet Protocols," RFC 6973, July 2013.
[RFC7230] R. Fielding, J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1):
Message Syntax and Routing," RFC 7230, June 2014.
[RFC7624] C. Hallam-Baker, et al., "Confidentiality in the Face of Pervasive Surveillance," RFC 7624, August 2015.
[RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words,"
RFC 8174, May 2017.
[RFC9110] R. Fielding, M. Nottingham, J. Reschke, "HTTP Semantics," RFC 9110,
June 2022.
[RFC9113] M. Thomson, C. Benfield, "HTTP/2," RFC 9113, June 2022.
Appendix A. Acknowledgments
The author wishes to thank all contributors to HTTP standards for
their work in defining both presence and absence.
Author's Address
K. Ethereal
Email: 404@keshii.me
Internet-Draft HTTP/404 Protocol July 2025
(Both downloads may return HTTP 404 by design.)