errata logo graphic

Found 9 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: Held for Document Update (3)

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.


Errata ID: 4436

Status: Held for Document Update
Type: Editorial

Reported By: Aron Duby
Date Reported: 2015-08-06
Held for Document Update by: Barry Leiba
Date Held: 2015-08-07

Section 4.3.5 says:

If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted, a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied,
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

It should say:

If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted; a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied;
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

Notes:

Using a semicolon creates a stronger delineation of the different options. If you are just quickly trying to parse what status to return if the delete hasn't happened yet and you quickly read "has not yet been enacted, a 204 (No Content)" you could incorrectly read that as return a 204. The semicolon makes it more obvious that "enacted" is the end of that thought and to scan backwards where as the comma in this instance requires knowing the structure of the rest of the paragraph.

----- Verifier Notes -----
There's no reason to use semicolons to delimit this list, because the list items themselves don't contain commas. Still, the reporter's confusion is noted. Perhaps a bullet list would be better in this case:

-------
If a DELETE method is successfully applied, the origin server SHOULD
send

- a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted,

- a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or

- a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.
-------


Errata ID: 4452

Status: Held for Document Update
Type: Editorial

Reported By: Attila Gulyas
Date Reported: 2015-08-22
Held for Document Update by: Barry Leiba
Date Held: 2015-08-22

Section 6.4 says:

Automatic redirection needs to done with
   care for methods not known to be safe, as defined in Section 4.2.1,
   since the user might not wish to redirect an unsafe request.

It should say:

Automatic redirection needs to be done with
   care for methods not known to be safe, as defined in Section 4.2.1,
   since the user might not wish to redirect an unsafe request.

Notes:

A simple typo ("needs to _be_ done")


Status: Rejected (5)

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

Status: Rejected
Type: Technical

Reported By: Nicolas Williams
Date Reported: 2015-04-29
Rejected by: Barry Leiba
Date Rejected: 2015-06-01

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.
--VERIFIER NOTES--
This is a change request, not an errata report. Such changes can be proposed in the working group's issue tracker, here:
https://github.com/httpwg/http11bis/issues


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