errata logo graphic

Found 7 records.

Status: Verified (1)

RFC7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Source of RFC: httpbis (app)

Errata ID: 4225

Status: Verified
Type: Editorial

Reported By: Bjoern Hoehrmann
Date Reported: 2015-01-09
Verifier Name: Barry Leiba
Date Verified: 2015-01-17

Section A. C & A. D says:

     field-name    = <comment, see [RFC7230], Section 3.2>

It should say:

     field-name    = <field-name, see [RFC7230], Section 3.2>

Notes:

field-name does not follow the `comment` production. The section number is correct.


Status: Reported (1)

RFC7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Source of RFC: httpbis (app)

Errata ID: 4351

Status: Reported
Type: Technical

Reported By: Nicolas Williams
Date Reported: 2015-04-29

Section 4.3.6 says:

   A server MUST NOT send any Transfer-Encoding or Content-Length header
   fields in a 2xx (Successful) response to CONNECT.  A client MUST
   ignore any Content-Length or Transfer-Encoding header fields received
   in a successful response to CONNECT.

   A payload within a CONNECT request message has no defined semantics;
   sending a payload body on a CONNECT request might cause some existing
   implementations to reject the request.

It should say:

   Historically no semantics have been defined for request and 2xx
   (Successful) response bodies for CONNECT, but nonetheless some clients
   and some servers do use request and 2xx response bodies.

   Servers MUST NOT send a response body in a 2xx (Successful) response
   to CONNECT.  Because some proxies send an initial flight of tunneled
   application data in 2xx response bodies, clients MUST accept response
   bodies in 2xx responses to CONNECT, and MUST treat the response body
   as the initial flight of application data.

   Servers that receive a CONNECT request body SHOULD treat it as the
   initial flight of tunneled application data.

Notes:

Implementing the original text ("A client MUST ignore...") has the effect
that the client will leave in the lower layer's buffer any 2xx CONNECT
response body, and when the Transfer-Encoding is the identity, then this
will have the effect that the 2xx response body is seamlessly prepended
to the tunneled application data in the server-to-client direction.
It seems almost like this was the intent of the original text, but if so,
then it would be much better to state this than to describe one possible
implementation approach.

Also, it seems rather unlikely that ignoring the Transfer-Encoding for any
TE other than the identity. If the proxy really did use a compression
or chunked transfer encoding, then ignoring this on the client side
(and prepending the encoded 2xx response body to the server-to-client
tunneled application data) would quite clearly be wrong.

It also seems that some clients send the first flight of tunneled
application data in a CONNECT request body. While historically the
semantics of CONNECT request and 2xx response bodies have not been
defined, it is worth pointing out that [it appears, so I'm told; see
below] some clients and some proxies rely on CONNECT request and 2xx
response bodies bearing the first flight of tunneled application data,
and if so, then the RFC should mention it. I'm not sure how much
evidence we can demand for such behaviors, but the RFC demands behavior
that implies the intent described in this erratum and gives no evidence
to support the need for such behavior, therefore it seems much better
to describe the previously-implied intent explicitly and continue with
a little-or-no-evidence approach that should nonetheless yield the most
interoperability.

Finally, I asked for clarification on the HTTPbis list, and the answers
I received indicate that the intent may have been as described in
these notes.

See https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0260.html
and follow-ups.


Status: Held for Document Update (1)

RFC7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Source of RFC: httpbis (app)

Errata ID: 4072

Status: Held for Document Update
Type: Editorial

Reported By: Martin Thomson
Date Reported: 2014-08-06
Held for Document Update by: Barry Leiba
Date Held: 2014-08-06

Section TOC says:

ed 

Notes:

Three extraneous characters "ed " appear before the table of contents entry for 7.1.1.


Status: Rejected (4)

RFC7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Source of RFC: httpbis (app)

Errata ID: 4031

Status: Rejected
Type: Technical

Reported By: Anne van Kesteren
Date Reported: 2014-06-30
Rejected by: Barry Leiba
Date Rejected: 2014-07-01

Section 3.1.1.1 says:

media-type = type "/" subtype *( OWS ";" OWS parameter )

It should say:

media-type = type "/" subtype *( OWS ";" OWS [parameter] )

Notes:

See the thread at http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0027.html

Implementations are much more relaxed when it comes to parsing MIME types.

The above is probably still too strict. E.g. requiring that a parameter contains "=" is something I doubt is actually the case in practice.
--VERIFIER NOTES--
The ABNF is there to specify what the expected productions are, and is correct as it stands: we do not *want* things such as these to be produced:

Content-Type: text/plain;
Content-Type: text/plain; charset=iso8859-1;
Content-Type: text/plain;;;;;;;;;;;; ;;; ;;; ;;;

That said, this report addresses a real problem: lack of direction to parsers on how to be appropriately lenient. Because the fact is that general interoperability of this stuff in the wild would be improved if parsers accepted at least the first two of the examples above, which are illegal by the grammar, but which do get generated by less-than-perfect implementations.

I'm marking this report as "Rejected" because the problem it means to address is much broader than this one case, and can't be fixed with an errata report. But it's important that we take up work on a document that does properly address this issue.


Errata ID: 4180

Status: Rejected
Type: Technical

Reported By: Michel Albert
Date Reported: 2014-11-14
Rejected by: Barry Leiba
Date Rejected: 2014-11-14

Section 6.4 says:

n/a

It should say:

n/a

Notes:

The section on status code 304 is missing even though that status code is mentioned in other parts of the document. RFC2616 described the status code as follows (in section 10.3.5):


> 10.3.5 304 Not Modified
>
> If the client has performed a conditional GET request and access is
> allowed, but the document has not been modified, the server SHOULD
> respond with this status code. The 304 response MUST NOT contain a
> message-body, and thus is always terminated by the first empty line
> after the header fields.
>
> The response MUST include the following header fields:
>
> - Date, unless its omission is required by section 14.18.1


This section would go right after "6.4.4. 303 See Other".
--VERIFIER NOTES--
Status code 304 relates to conditional requests, and is therefore documented in RFC 7232 (Section 4.1). This fact is shown in the table in RFC 7231, Section 6.1, and in the IANA registry "HTTP Status Codes" <http://www.iana.org/assignments/http-status-codes>.


Errata ID: 4232

Status: Rejected
Type: Technical

Reported By: Christopher Olson
Date Reported: 2015-01-14
Rejected by: Barry Leiba
Date Rejected: 2015-01-17

Section 7.1.1.1 says:

GMT

It should say:

+0000

Notes:

The text refers to RFC 5322. There Sect 3.3 calls the use timezone abbreviations, like GMT, obsolete. It encourages using a numeric offset such as +0000.

The grammar for dates in 7231 Sect 7.1.1.1 uses GMT. Example dates throughout this RFC and others related to HTTP use GMT. This is inconsistent with 5322.

The RFCs for HTTP need to be modified to match 5322, or 7.1.1.1 needs a note that HTTP deliberately deviates from 5322 with regards to the timezone.
--VERIFIER NOTES--
The document is quite clear that the "GMT" version is preferred, and is necessary for compatibility with earlier versions and implementations.


Errata ID: 4224

Status: Rejected
Type: Editorial

Reported By: Bjoern Hoehrmann
Date Reported: 2015-01-09
Rejected by: Barry Leiba
Date Rejected: 2015-01-17

Section 4.1 and A. D says:

     method = token

It should say:

     method = <method, see [RFC7230], Section 3.1.1>

Notes:

The HTTP/1.1 RFCs define rules imported across documents using prose rules for all rules except this one. This is an error because RFC7231 does not mean to re-define the production rule.
--VERIFIER NOTES--
This is asking for an editorial change, but the errata system is not the place to record proposals for editorial improvements. There is an issue tracker at <https://github.com/httpwg/http11bis/issues> for keeping issues for a possible future HTTP 1.1 update.


Report New Errata