RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 19 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

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

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

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

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

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

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

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

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 (3)

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

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: 5216

Status: Reported
Type: Technical

Reported By: Jingcheng Zhang
Date Reported: 2017-12-25

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.

Errata ID: 5257

Status: Reported
Type: Technical

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.

Status: Held for Document Update (4)

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

Source of RFC: httpbis (app)

Errata ID: 4189

Status: Held for Document Update
Type: Technical

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

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: 4779

Status: Held for Document Update
Type: Editorial

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

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 (4)

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

Source of RFC: httpbis (app)

Errata ID: 4412

Status: Rejected
Type: Technical

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

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: 4136

Status: Rejected
Type: Editorial

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

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.

Report New Errata