errata logo graphic

Found 8 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: Reported (1)

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

Source of RFC: httpbis (app)

Errata ID: 4189

Status: Reported
Type: Technical

Reported By: Simon Schueppel
Date Reported: 2014-11-26

Section 3.2 says:

     header-field   = field-name ":" OWS field-value OWS

     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:

    header-field   = field-name ":" FWS field-value FWS
    
    field-name     = token
    FWS            = field-ows
    field-value    = [ field-vchar *( field-ows field-vchar ) ]
    field-vchar    = VCHAR / obs-text
    field-ows      = *( SP / HTAB ) *obs-fold
    
    obs-fold       = 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


Status: Rejected (2)

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

Source of RFC: httpbis (app)

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