errata logo graphic

Found 6 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 (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