- From: RFC Errata System <rfc-editor@rfc-editor.org>
- Date: Mon, 15 Apr 2019 07:02:55 -0700 (PDT)
- To: mvjames@ieee.org, fielding@gbiv.com, julian.reschke@greenbytes.de
- Cc: aamelnikov@fastmail.fm, iesg@ietf.org, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
The following errata report has been rejected for RFC7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5599 -------------------------------------- Status: Rejected Type: Technical Reported by: Michael James <mvjames@ieee.org> Date Reported: 2019-01-13 Rejected by: Alexey Melnikov (IESG) Section: GLOBAL Original Text ------------- 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. ... Corrected Text -------------- 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> -------------------------------------- RFC7230 (draft-ietf-httpbis-p1-messaging-26) -------------------------------------- Title : Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Publication Date : June 2014 Author(s) : R. Fielding, Ed., J. Reschke, Ed. Category : PROPOSED STANDARD Source : Hypertext Transfer Protocol Bis APP Area : Applications Stream : IETF Verifying Party : IESG
Received on Monday, 15 April 2019 14:03:42 UTC