RFC Errata
Found 24 records.
Status: Verified (8)
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: 4169
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Schueppel
Date Reported: 2014-11-09
Verifier Name: Barry Leiba
Date Verified: 2014-11-10
Section 7 says:
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) Empty elements do not contribute to the count of elements present. For example, given these ABNF productions: example-list = 1#example-list-elmt example-list-elmt = token ; see Section 3.2.6 Then the following are valid values for example-list (not including the double quotes, which are present for delimitation only): "foo,bar" "foo ,bar," "foo , ,bar,charlie "
It should say:
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) Empty elements do not contribute to the count of elements present. For example, given these ABNF productions: example-list = 1#example-list-elmt example-list-elmt = token ; see Section 3.2.6 Then the following are valid values for example-list (not including the double quotes, which are present for delimitation only): "foo,bar" "foo ,bar," "foo , ,bar,charlie"
Notes:
"foo , ,bar,charlie " cannot be derived from 1#token (legacy list rule)
"foo , ,bar,charlie" can be derived from 1#token (legacy list rule)
Errata ID: 4251
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bjoern Hoehrmann
Date Reported: 2015-02-01
Verifier Name: Barry Leiba
Date Verified: 2015-02-01
Section 2.7.1 says:
http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ]
It should say:
http-URI = "http:" "//" authority path-abempty [ "?" query ]
Notes:
Per http://tools.ietf.org/html/rfc3986#section-4.3 "URI scheme specifications must define their own syntax so that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar." See the discussion around http://mailarchive.ietf.org/arch/msg/apps-discuss/gZVRtgOUFyzOk68FgL1jHTzWG2s
Errata ID: 4252
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bjoern Hoehrmann
Date Reported: 2015-02-01
Verifier Name: Barry Leiba
Date Verified: 2015-02-01
Section 2.7.2. says:
https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ]
It should say:
https-URI = "https:" "//" authority path-abempty [ "?" query ]
Notes:
See erratum 4251 on the same document.
Errata ID: 4667
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Rousskov
Date Reported: 2016-04-13
Verifier Name: Alexey Melnikov
Date Verified: 2016-10-07
Section 4.1.1 says:
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
It should say:
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] )
Notes:
The infamous "implicit *LWS" syntax rule in RFC 2616 allowed whitespace between
";" and chunk-ext-name in chunk-ext. Some HTTP agents generate that whitespace.
In my experience, HTTP agents that can parse chunk extensions usually can handle
that whitespace. Moreover, ICAP, which generally relies on HTTP/1 for its message
syntax, uses that whitespace when defining the "ieof" chunk extension in RFC 3507
Section 4.5:
\r\n
0; ieof\r\n\r\n
IMHO, RFC 7230 should either allow BWS before chunk-ext-name or at the very least
explicitly document the HTTP/1 syntax change and its effect on parsers used for both
ICAP and HTTP/1 messages (a very common case for ICAP-supporting HTTP
intermediaries and ICAP services).
I also recommend adding BWS around "=", for consistency and RFC 2616 backward
compatibility reasons. HTTPbis RFCs already do that for transfer-parameter and
auth-param that have similar syntax.
Please also consider adding BWS _before_ ";" for consistency and RFC 2616 backward
compatibility reasons. HTTPbis RFCs already do that for transfer-extension,
accept-ext, t-ranking, and other constructs with similar syntax.
Errata ID: 4825
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Rousskov
Date Reported: 2016-04-13
Verifier Name: Alexey Melnikov
Date Verified: 2016-10-07
Section Appendix B says:
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
It should say:
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] )
Notes:
The infamous "implicit *LWS" syntax rule in RFC 2616 allowed whitespace between
";" and chunk-ext-name in chunk-ext. Some HTTP agents generate that whitespace.
In my experience, HTTP agents that can parse chunk extensions usually can handle
that whitespace. Moreover, ICAP, which generally relies on HTTP/1 for its message
syntax, uses that whitespace when defining the "ieof" chunk extension in RFC 3507
Section 4.5:
\r\n
0; ieof\r\n\r\n
IMHO, RFC 7230 should either allow BWS before chunk-ext-name or at the very least
explicitly document the HTTP/1 syntax change and its effect on parsers used for both
ICAP and HTTP/1 messages (a very common case for ICAP-supporting HTTP
intermediaries and ICAP services).
I also recommend adding BWS around "=", for consistency and RFC 2616 backward
compatibility reasons. HTTPbis RFCs already do that for transfer-parameter and
auth-param that have similar syntax.
Please also consider adding BWS _before_ ";" for consistency and RFC 2616 backward
compatibility reasons. HTTPbis RFCs already do that for transfer-extension,
accept-ext, t-ranking, and other constructs with similar syntax.
Errata ID: 4839
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Etan Kissling
Date Reported: 2016-10-23
Verifier Name: Alexey Melnikov
Date Verified: 2017-02-16
Section 4 says:
Parameters are in the form of a name or name=value pair. transfer-parameter = token BWS "=" BWS ( token / quoted-string )
It should say:
Parameters are in the form of a name=value pair. transfer-parameter = token BWS "=" BWS ( token / quoted-string )
Notes:
The ABNF does not allow the form of a name.
Errata ID: 4050
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daisuke Miyakawa
Date Reported: 2014-07-11
Verifier Name: Barry Leiba
Date Verified: 2014-07-12
Section 3.2.4 says:
A server MUST reject any received request message that contains whitespace between a header field-name and colon with a response code of 400 (Bad Request).
It should say:
A server MUST reject any received request message that contains whitespace between a header field-name and colon with a status code of 400 (Bad Request).
Notes:
Basically HTTP RFCs seem to prefer "status code" over "response code". RFC 7231 Section 6 uses status code or "Response Status Code", but rarely uses the term "response code" (though it uses it, once). Some technical books actually refer those codes as "response codes". I tend to be confused with the mixture of those two terms.
Errata ID: 4205
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Semyon Kholodnov
Date Reported: 2014-12-23
Verifier Name: Barry Leiba
Date Verified: 2014-12-25
Section 6.3 says:
o If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy, and the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise,
It should say:
o If the received protocol is HTTP/1.0, the "keep-alive" connection option is present in a message that is not a request to a proxy, and the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise,
Notes:
The correction makes it clearer that the reference is meant to be client-to-proxy and not proxy-to-server.
Status: Held for Document Update (7)
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: 4189
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon Schueppel
Date Reported: 2014-11-26
Held for Document Update by: Barry Leiba
Date Held: 2015-04-22
Section 3.2 says:
field-name = token field-value = *( field-content / obs-fold ) field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-vchar = VCHAR / obs-text obs-fold = CRLF 1*( SP / HTAB ) ; obsolete line folding ; see Section 3.2.4
It should say:
field-name = token field-value = *( field-content / obs-fold ) field-content = field-vchar [ 1*( SP / HTAB / field-vchar ) field-vchar ] field-vchar = VCHAR / obs-text obs-fold = OWS CRLF 1*( SP / HTAB ) ; obsolete line folding ; see Section 3.2.4
Notes:
the field-value rule given in Section 3.2 will not recognize several strings recognized by specific header rules.
Examples:
- ", , ," recognized by legacy list rule
- "abrowser/0.001 (C O M M E N T)" recognized by User-Agent rule
- "gzip , chunked" recognized by Transfer-Encoding rule
- etc.
General Problem:
the specified field-value rule does not allow single field-vchar surrounded by whitespace anywhere
Further Notes:
-what the authors propably wanted to say:
a string of octets is a field-value if, and only if:
-it is *( field-vchar / SP / HTAB / obs-fold )
-if it is not empty, it starts and ends with field-vchar
-the suggested correction was designed according to these criteria
--------------------- Notes from verifier ---------------------
This has been edited from the original report after discussion, but even this is not right. There's more here than can be reasonably fixed in an errata report, and the proper fix needs to be done in a revision of the document -- hence, "Held for Document Update". Note that this *is* a valid report, and that a fix is needed. The one above is the best approach for now, and a better fix will be developed in 7230bis.
Errata ID: 4683
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Daurnimator
Date Reported: 2016-05-04
Held for Document Update by: Alexey Melnikov
Date Held: 2016-05-05
Section 4 says:
It should say:
The name part of a transfer-parameter is case insensitive and MUST not be "q" (as this would be ambiguous when used as part of the TE header).
Notes:
Nothing is said about how to handle transfer-parameters.
Notably, nothing is said about the case sensitivity of the parameter key.
This results in a conflict with the TE header: if you see a "q" token,
you cannot know if it is a transfer-parameter vs a t-ranking.
It *is* noted that the "q" token is case insensitive in section 4.3.
> When multiple transfer codings are acceptable, the client MAY rank
> the codings by preference using a case-insensitive "q" parameter
Alexey: as per Mark, this should be discussed in the HTTPBis WG.
Errata ID: 5163
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Matson
Date Reported: 2017-10-20
Held for Document Update by: Francesca Palombini
Date Held: 2021-08-23
Section 3.2.4 says:
A field value might be preceded and/or followed by optional whitespace (OWS); a single SP preceding the field-value is preferred for consistent readability by humans. The field value does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet of the field value ought to be excluded by parsers when extracting the field value from a header field.
It should say:
A field value might be preceded and/or followed by optional whitespace (OWS); a single SP preceding the field-value is preferred for consistent readability by humans. The field value does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet of the field value ought to be excluded by parsers when extracting the field value from a header field. All optional whitespace between tokens in field-content has the same semantics as SP. Any sequence of SP / HTAB that occurs between tokens in field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.
Notes:
RFC 2616, section 2.2, contained the following text:
All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
Similarly, RFC 2616 section 4.2 contained the following text:
Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.
In section A.2. Changes from RFC 2616, the document does not list any intended change for how space and tab are handled, but the current text does appear to constitute a change. I suspect the change is accidental due to rewording the document when line folding was made deprecated.
Note that in RFC 2616, LWS is defined as follows:
LWS = [CRLF] 1*( SP | HT )
In particular, the leading CRLF was optional.
Thus, the wording in RFC 2616 covered two cases:
1. LWS that includes line folding.
2. LWS that does not include line folding.
The current text does cover how to handle case #1 - former LWS that began with a CRLF; later in section 3.2.4 it requires rejecting or replacing with SP. (The old "MAY" language has effectively become a "MUST" for the leading CRLF case.)
However, the current text does not appear to address case #2 - former LWS that does not begin with a CRLF - in other words, SP and HTAB occurring between field-content. I suspect the intention is still that a recipient should treat such whitespace as insignificant, and may replace any sequence of SP and HTAB with a single SP before interpreting the field content, but I believe the text of the current RFC no longer provides this behavior.
(I have not read all of the specifications in full, so please accept my apologies if I have misread or missed a relevant portion elsewhere.)
Errata ID: 5257
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erwin Pe
Date Reported: 2018-02-07
Held for Document Update by: Francesca Palombini
Date Held: 2021-08-23
Section 7 says:
For compatibility with legacy list rules, a recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism. In other words, a recipient MUST accept lists that satisfy the following syntax: #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
It should say:
For compatibility with legacy list rules, a recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism. In other words, a recipient MUST accept lists that satisfy the following syntax: #element => [ ( ("," OWS element) / element ) *( OWS "," [ OWS element ] ) ] 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Notes:
With the current ABNF rule for #element, and using token as an element, the construction:
", foobar"
cannot be derived from #element, but can be derived from 1#element. (legacy list rule)
Since #element is meant to be a superset of 1#element, lists derived from 1#element should satisfy the #element rule as well.
Errata ID: 5964
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2020-01-23
Held for Document Update by: Barry Leiba
Date Held: 2020-02-05
Section 2.7.1 says:
The URI generic syntax for authority also includes a deprecated userinfo subcomponent ([RFC3986], Section 3.2.1) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password. A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks.
It should say:
The URI generic syntax for authority also includes a userinfo subcomponent in which the format "user:password" is deprecated ([RFC3986], Section 3.2.1). The user is permitted, but the password is not. Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password. A sender MUST NOT generate a colon in a userinfo subcomponent when an "http" URI reference is generated within a message as a request target or header field value, but it may prefix a user and an "@" delimiter before the host name in an "http" URI. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat the presence of a colon in it as an error.
Notes:
RFC3986 does not forbid or even discourage the "user" in the userinfo subcomponent. It only says
Use of the format "user:password" in the userinfo field is
deprecated.
and continues to describe ":password" handling.
Obscuring the authority for the purposes of phishing is not mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility. Parsing does help against misleading password popups.
The user is part of the authority section of the URI and its purpose is to zoom in on a scope for authoritative resource addressing. This syntax has in the past been (ab)used for Basic/Digest authentication details, which only works if visitor and visited resource happen to be the same user; it is this (ab)use that is now deprecated.
===========================
Verifier notes:
This is not really an erratum, as the document says exactly what it was intended to say when it was written. That said, the issue does need to be discussed as the document is updated, and an update is planned... so I'm marking it "Held for Document Update", rather than "Rejected".
Errata ID: 4779
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: William A. Rowe Jr.
Date Reported: 2016-08-18
Held for Document Update by: Alexey Melnikov
Date Held: 2016-10-07
Section A.2. says:
[...] Non-US-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (Section 3.2.6)
It should say:
[...] Non-US-ASCII content in header field values and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (Section 3.2.6)
Notes:
Section 3.2 plainly states header field names are token
(VCHARs less separators) as defined in 3.2.6.
The "header fields" identified in this footnote are neither
clear nor correct.
Alexey: While this is a clarification, the whole section is likely to be deleted when the document is revised.
Errata ID: 4891
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mike Bishop
Date Reported: 2016-12-16
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23
Section 3.2.6 says:
qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
It should say:
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
Notes:
Lack of space between the slash and the alternative makes it unclear that the slash isn't part of the next alternative.
Mark Nottingham: Not a bug, but certainly an improvement.
Status: Rejected (9)
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: 4412
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick Taylor
Date Reported: 2015-07-09
Rejected by: Barry Leiba
Date Rejected: 2015-07-09
Section 3.3.3 says:
If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.
It should say:
Either: If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server. Or: If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.
Notes:
The paragraph has two apparently contradictory rules. It is unclear which is the correct behaviour.
--VERIFIER NOTES--
They're not contradictory: the first is for responses and the second is for requests, which are different situations.
Errata ID: 4838
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Etan Kissling
Date Reported: 2016-10-22
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-16
Section 4 says:
Parameters are in the form of a name or name=value pair. transfer-parameter = token BWS "=" BWS ( token / quoted-string )
It should say:
Parameters are in the form of a name or name=value pair. transfer-parameter = token / token BWS "=" BWS ( token / quoted-string )
Notes:
The form of a name cannot be represented with the original ABNF.
--VERIFIER NOTES--
Rejected as per the mailing list discussion:
<https://www.w3.org/Search/Mail/Public/search?type-index=ietf-http-wg&index-type=t&keywords=4838&search=Search>
Errata ID: 5216
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jingcheng Zhang
Date Reported: 2017-12-25
Rejected by: Alexey Melnikov
Date Rejected: 2018-07-26
Section 5.4. says:
A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.7.1). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field-value.
It should say:
A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.7.1). If the authority component is missing or undefined for the target URI, then a recipient MUST reject this request.
Notes:
First,
If the target URI includes an authority component, then a
client MUST send a field-value for Host that is identical to that
authority component.
Secondly, section 2.7.1 said:
A sender MUST NOT generate an "http" URI with an empty host
identifier. A recipient that processes such a URI reference MUST
reject it as invalid.
So a recipient MUST reject a request with empty authority.
--VERIFIER NOTES--
As per Roy T. Fielding: Reject. A target URI can be any URI scheme.
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>
Errata ID: 6333
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeff Brower
Date Reported: 2020-11-13
Rejected by: Barry Leiba
Date Rejected: 2020-11-13
Section 3.2.6 (PDF) says:
tchar = "!" / "#" / "$" / "%" / "&" / "’" / "*" / "+" / "-" / "." / "^" / "_" / "‘" / "|" / "~"
It should say:
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
Notes:
The generated PDF contains misleading right and left quotes (U+8217 and U+8216), which are not ASCII characters. The text and html versions of the RFC have the correct apostrophe and grave accent characters (' and `).
--VERIFIER NOTES--
Errata reports only apply to the canonical version of the published RFCs; in this case, that's the rfc7230.txt file, not the generated PDF.
Errata ID: 4136
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Gevaerts
Date Reported: 2014-10-20
Rejected by: Barry Leiba
Date Rejected: 2014-10-21
Section A.2. says:
Bogus Content-Length header fields are now required to be handled as errors by recipients. (Section 3.3.2)
It should say:
Bogus Content-Length header fields are now required to be handled as errors by recipients. (Section 3.3.3)
Notes:
The mentioned requirement appears in 3.3.3 (5), not in 3.3.2
--VERIFIER NOTES--
The text in 3.3.3 is not what this item is referring to: it really is referring to Section 3.3.2 as a whole.
Errata ID: 4281
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Demian Brecht
Date Reported: 2015-02-26
Rejected by: Barry Leiba
Date Rejected: 2015-03-01
Section 3.3.2 says:
For messages that do not include a payload body, the Content-Length indicates the size of the selected representation (Section 3 of [RFC7231]).
It should say:
For outbound messages that do not include a payload body, the Content-Length indicates the size of the selected representation (Section 3 of [RFC7231]).
Notes:
Assuming my interpretation is correct, this phrase as-is is a little confusing given the next paragraphs states:
"A user agent SHOULD NOT send a Content-Length header field when the request message does not contain a payload body and the method semantics do not anticipate such a body."
The former is ambiguous, the latter explicit.
--VERIFIER NOTES--
The sentence in question has to be taken in context with the entire paragraph, with the rest of the section, and with the understand that it's only a summary. The details are provided in the rest of the section and in Section 3.3.3.
Errata ID: 5623
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Armin Abfalterer
Date Reported: 2019-02-05
Rejected by: Alexey Melnikov
Date Rejected: 2019-04-15
Section 2.7 says:
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
Notes:
RFC3986 defines "absolute-URI" very openly, especially regarding to "hier-part":
absolute-URI = scheme ":" hier-part [ "?" query ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
The impact is reflected in RFC 7231 in the definition of the header fields Referer and Content-Location.
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
Thus, following examples of header values are considered valid
Referer: https:foo/bar
Referer: https:/foo
Referer: https:/
Referer: foo:/
I'd suggest to define "hier-part" (but also "scheme") more strictly.
--VERIFIER NOTES--
As per WG discussion: <https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0130.html>
Errata ID: 6565
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alissa Tung
Date Reported: 2021-04-29
Rejected by: Francesca Palombini
Date Rejected: 2021-04-29
Section section-6.3 says:
o If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy, and the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise, o The connection will close after the current response.
It should say:
o If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy, and the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise, the connection will close after the current response.
Notes:
Error on breaking paragraph.
--VERIFIER NOTES--
This paragraph split into two bullets was meant to be as is in the document, for readability.