errata logo graphic

Found 9 records.

Status: Verified (5)

RFC7230, "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: 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: Held for Document Update (1)

RFC7230, "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.


Status: Rejected (3)

RFC7230, "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: 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