RFC Errata
Found 8 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.