RFC Errata
Found 16 records.
Status: Verified (6)
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999
Note: This RFC has been obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235
Note: This RFC has been updated by RFC 2817, RFC 5785, RFC 6266, RFC 6585
Source of RFC: http (app)
Errata ID: 408
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Greg Robson
Date Reported: 2001-10-08
Section 3.6 says:
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
Notes:
There is no section 3.6.2; there is no such thing as Transfer-Coding:
identity in the RFC 2616 specification (note that there would not be
quotes around "identity" in the actual header!).
Errata ID: 412
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Justin Erenkrantz
Date Reported: 2001-01-05
Report Text:
From Scott Lawrence: All known errata for this HTTP RFC will be found at: http://purl.org/NET/http-errata and http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/
Errata ID: 411
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: WooJin Chung
Date Reported: 2006-10-31
Verifier Name: Barry Leiba
Date Verified: 2014-06-03
Section 14.3 says:
The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (section 3.5) that are acceptable in
the response.
Accept-Encoding = "Accept-Encoding" ":"
1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
Examples of its use are:
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
It should say:
The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (section 3.5) that are acceptable in
the response.
Accept-Encoding = "Accept-Encoding" ":"
1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
Examples of its use are:
Accept-Encoding: compress, gzip
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
Notes:
As you can see, Accept-Encoding has to consist of 1 or more ( codings [ ";"
"q" "=" qvalue ] ). So you can't just leave the value of "Accept-Encoding:"
empty. The second example is, therefore, incorrect.
------------------------------------------------
Alexey: This issue was fixed in HTTPBIS WG, see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/25>
Errata ID: 652
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Erenkrantz
Date Reported: 2000-12-23
Section 4.4 says:
4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self- elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse it; the presence in a request of a Range header with ultiple byte- range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses.
It should say:
4.If the message uses the media type "multipart/byteranges", and the Transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type MUST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte- range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.
Notes:
Missing the first character of 6 words.
Errata ID: 653
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Justin Erenkrantz
Date Reported: 2000-12-23
Section 1.3 says:
Each of these representations is termed a `varriant'.
It should say:
Each of these representations is termed a `variant'.
Errata ID: 4522
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe JAILLET
Date Reported: 2015-11-03
Verifier Name: Barry Leiba
Date Verified: 2016-01-21
Section 13.5.1 says:
The following HTTP/1.1 headers are hop-by-hop headers:
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- TE
- Trailers
- Transfer-Encoding
- Upgrade
It should say:
The following HTTP/1.1 headers are hop-by-hop headers:
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- TE
- Trailer
- Transfer-Encoding
- Upgrade
Notes:
Trailers (with a s) does not seem to a header field, just a keyword for TE.
I think that Trailer (without a s) is expected here.
AFAIK, RFC 7230 does not have such an explicit list and is not concerned.
Status: Held for Document Update (5)
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999
Note: This RFC has been obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235
Note: This RFC has been updated by RFC 2817, RFC 5785, RFC 6266, RFC 6585
Source of RFC: http (app)
Errata ID: 3407
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Lane
Date Reported: 2012-11-14
Held for Document Update by: Barry Leiba
Date Held: 2012-11-27
Section 2.2 says:
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
In all other fields, parentheses are considered part of the field
value.
comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs.
quoted-pair = "\" CHAR
It should say:
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
In all other fields, parentheses are considered part of the field
value.
comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "\", "(" and ")">
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT excluding "\" and <">>
The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs.
quoted-pair = "\" CHAR
Notes:
Allowing "\" in qdtext and ctext creates ambiguous semantics.
Consider:
" \" (\ was a qdtext, so string has terminated)
" \""(\ is part of the quoted pair \")
" \ " (Is this an escaped space or a bare backslash?)
" \\"" (first \ is qdtext and second \ is part of quoted-pair \")
Analogous examples would work for ctext and comment, as well.
It looks to me as though the intended meaning was for the implementer to consider "\" part of a quoted-pair whenever possible. It's always possible, so the obvious fix would be to exclude it from ctext and qdtext, and use \\ whenever the user desires a textual backslash.
--- VERIFIER NOTES ---
This issue is already being dealt with in the HTTP 1.1 work in the HTTPBIS working group. The 2616 updates, which will be published soon, will include fixes for this.
Errata ID: 892
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: WooJin Chung
Date Reported: 2006-10-31
Held for Document Update by: Peter Saint-Andre
Section 4.4 says:
4. If the message uses the media type "multipart/byteranges", and the
ransfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length.
It should say:
4. If the message uses the media type "multipart/byteranges", and the
transfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length.
Errata ID: 1483
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Kong
Date Reported: 2008-08-06
Held for Document Update by: Peter Saint-Andre
Section 3.6 says:
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
It should say:
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.5), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
Notes:
The tokens for Content-Codings are defined in section 3.5. These include the identity token.
Errata ID: 1619
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Heming Hou
Date Reported: 2008-11-25
Held for Document Update by: Peter Saint-Andre
Section 4.4 says:
4.If the message uses the media type "multipart/byteranges", and the
ransfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length. This media type
UST NOT be used unless the sender knows that the recipient can arse
it; the presence in a request of a Range header with ultiple byte-
range specifiers from a 1.1 client implies that the lient can parse
multipart/byteranges responses.
It should say:
4.If the message uses the media type "multipart/byteranges", and the
transfer-length is not otherwise specified, then this self-
delimiting media type defines the transfer-length. This media type
MUST NOT be used unless the sender knows that the recipient can parse
it; the presence in a request of a Range header with multiple byte-
range specifiers from a 1.1 client implies that the client can parse
multipart/byteranges responses.
Notes:
> "ransfer-length" should be "transfer-length"
> "self-elimiting" should be "self-delimiting";
> "UST"should be "MUST";
> "arse"should be "parse";
> "ultiple"should be "multiple";
> "lient"should be "client";
Errata ID: 3206
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: ValCot
Date Reported: 2012-04-27
Held for Document Update by: Barry Leiba
Section 1.3 says:
variant
A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these
representations is termed a `varriant'. Use of the term `variant'
does not necessarily imply that the resource is subject to content
negotiation.
It should say:
variant
A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these
representations is termed a `variant'. Use of the term `variant'
does not necessarily imply that the resource is subject to content
negotiation.
Notes:
"varriant" Is this misspelling?
Status: Rejected (5)
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999
Note: This RFC has been obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235
Note: This RFC has been updated by RFC 2817, RFC 5785, RFC 6266, RFC 6585
Source of RFC: http (app)
Errata ID: 2301
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Conrad Roche
Date Reported: 2010-06-14
Rejected by: Alexey Melnikov
Date Rejected: 2010-07-07
Section 14.36 says:
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
It should say:
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from whose message-body the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
Notes:
The text should mention that the referrer is specified when the URI was obtained from the message-body of the Request-URI.
For instance, when the user agent receives a 302 response for a Request-URI, it does not specify the original Request-URI in the referrer header for the subsequent request - even though the (redirect) URI "was obtained" from the (header of the) 302 response for the original Request-URI.
Roy T. Fielding replied:
I think this should be rejected. The referrer is the redirect.
User agents should be sending the redirecting URI in Referer,
or sending nothing in Referer.
In any case, see the Link header field. It is certainly possible
to be referred by something in the header fields, so saying that it
is in the message-body would be incorrect.
--VERIFIER NOTES--
As per the reply from Roy T. Fielding.
Errata ID: 2998
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Moutinho
Date Reported: 2011-10-15
Rejected by: Peter Saint-Andre
Date Rejected: 2011-10-17
Section 3.2.1 says:
For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]).
It should say:
For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 3986 [<ref>] (which updates RFCs 1738 [4] and replaces RFC 1808 [11] and RFC 2396 [42]).
Notes:
<ref> should be added
--VERIFIER NOTES--
The reader can follow the chain of document updates from RFC 2396 to RFC 3986, which is why we do not modify published RFCs to track document updates for referenced specifications. In any case, the updated HTTP RFCs (being produced by the HTTPBIS WG) will contain the appropriate references.
Errata ID: 3056
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Moutinho
Date Reported: 2011-12-20
Rejected by: Peter Saint-Andre
Date Rejected: 2011-12-21
Section 5.1.2 says:
Request-URI = "*" | absoluteURI | abs_path | authority
It should say:
Request-URI = "*" | absoluteURI | abs_path [ "?" query ] | authority
Notes:
so that "/path?query" is a valid Request-URI as it should.
because it is not the case with RFC 3986
(obsoleting RFC 2396 which has the same problem actually):
absoluteURI = absolute-URI
abs_path = path-absolute
absolute-URI = scheme ":" hier-part [ "?" query ]
path-absolute = "/" [ segment-nz *( "/" segment ) ]
segment-nz = 1*pchar
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
--VERIFIER NOTES--
This issue has been fixed in the revisions to RFC 2616, see http://trac.tools.ietf.org/wg/httpbis/trac/changeset/76
Errata ID: 2645
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Winfred Qin
Date Reported: 2010-11-27
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-03
Section 3.5 says:
Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with previous implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
It should say:
Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with future implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
Notes:
"For compatibility with previous implementations of HTTP",
here, 'previous' should be replaced by 'future'.
--VERIFIER NOTES--
Comment by Peter Saint-Andre:
This erratum is incorrect -- the text is clearly about
backward compatibility, not forward compatibility. The
original poster can comment in the HTTPBIS WG about this
matter since draft-ietf-httpbis-p1-messaging has very
similar text.
Errata ID: 2806
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carlos McEvilly
Date Reported: 2011-05-12
Rejected by: RFC Editor
Date Rejected: 2011-05-16
Section 14.13 says:
Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#section- ">section</a> <a href="#section- ">4.4</a>.
It should say:
Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#section-4.4">section 4.4</a>.
Notes:
This errata refers to the linkified version of the RFC at:
http://tools.ietf.org/html/rfc2616
Note that the original and corrected text above both contain HTML tags. In case the text doesn't survive the form submission, just to describe the problem, the link in the text shown, an internal anchor link that should point to #section-4.4, is broken because the number 4.4 is missing at the end of the anchor inside the href quotes.
--- VERIFIER NOTES ---
This report has been rejected because it is regarding a link in the HTML version of the RFC on tools.ietf.org. The report has been directed to webmaster@tools.ietf.org.
Errata are for the RFCs as available from rfc-editor.org.