errata logo graphic

Found 3 records.

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 (2)

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>.


Report New Errata