RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", June 2014

Source of RFC: httpbis (app)

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>

Report New Errata