Re: [Technical Errata Reported] RFC7230 (5599)

Reject, please. This is out of scope for an errata. However, we are working on a revision of the core specifications, see:
  https://github.com/httpwg/http-core#draft-http-core-documents

Also, there's recently been discussion on evolving User-Agent in HTTP, see start here:
   https://www.w3.org/mid/CAKXHy=eHiMtXi8vkDYtADHdU0tnUfd3p+Wfy7vSkLgT7cA1W0w@mail.gmail.com

Cheers,


> On 13 Jan 2019, at 12:26 pm, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted 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
> 
> --------------------------------------
> Type: Technical
> Reported by: Michael James <mvjames@ieee.org>
> 
> 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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> 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

--
Mark Nottingham   https://www.mnot.net/

Received on Sunday, 13 January 2019 03:13:39 UTC