RFC Errata
RFC 7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", June 2014
Note: This RFC has been obsoleted by RFC 9110, RFC 9112
Note: This RFC has been updated by RFC 8615
Source of RFC: httpbis (wit)
Errata ID: 5599
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael James
Date Reported: 2019-01-13
Rejected by: Alexey Melnikov
Date Rejected: 2019-04-15
Throughout the document, when it says:
2.3. Intermediaries ... HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers. Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent. 2.5. Conformance and Error Handling ... A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics. For example, an origin server might disregard the contents of a received Accept-Encoding header field if inspection of the User-Agent header field indicates a specific implementation version that is known to fail on receipt of certain content codings. ... 2.6. Protocol Versioning ... A server MAY send an HTTP/1.0 response to a request if it is known or suspected that the client incorrectly implements the HTTP specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the given minor version of the protocol. Such protocol downgrades SHOULD NOT be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., User-Agent) uniquely match the values sent by a client known to be in error. ...
It should say:
2.3. Intermediaries ... HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers. Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent. User agents MUST include a User-Agent request-header field with CONNECT and individual query requests that uniquely identify the product making the request thru an intermediary. 2.5. Conformance and Error Handling ... A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics. For example, an origin server might disregard the contents of a received Accept-Encoding header field if inspection of the User-Agent header field indicates a specific implementation version that is known to fail on receipt of certain content codings. User agents MUST include a User-Agent request-header field with CONNECT and individual query requests that uniquely identify the product making the request. ... 2.6. Protocol Versioning ... A server MAY send an HTTP/1.0 response to a request if it is known or suspected that the client incorrectly implements the HTTP specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the given minor version of the protocol. Such protocol downgrades SHOULD NOT be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., User-Agent) uniquely match the values sent by a client known to be in error. User agents MUST include a User-Agent request-header field with CONNECT and individual query requests that uniquely identify the product making the request. ...
Notes:
User agents MUST include a User-Agent
request-header field with CONNECT and individual query requests that
uniquely identify the product making the request thru an intermediary.
RFC 2616 Sec 14.43 specified made the "User-Agent" request-header as optional "User agents SHOULD include this field with requests." But RFC7230 drops most mentions of the User-Agent request-header field. Without this field intermediaries are left guessing.
Most of the complaints against including the User-Agent header is the monstrosity they have become an the spoofing. Even if the field only contains a SHA-256 hash of the binary making the request, this would differentiate between processes. But having it is still better from a security and interoperability perceptive.
--VERIFIER NOTES--
See WG summary at <https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0029.html>