RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (8)

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

Source of RFC: httpbis (app)

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: Reported (2)

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

Source of RFC: httpbis (app)

Errata ID: 5163
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: David Matson
Date Reported: 2017-10-20

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: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Erwin Pe
Date Reported: 2018-02-07

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.

Report New Errata