|
|
|
|
Found 9 records.
Errata ID: 408
Status: Verified
Type: Technical
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
Reported By:
Date Reported: 2001-01-05
Report Text:
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: 652
Status: Verified
Type: Editorial
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
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: 411
Status: Reported
Type: Technical
Reported By: WooJin Chung
Date Reported: 2006-10-31
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:
[not supplied]
Notes:
As you can see, Accept-Encoding has to consist of 1 or more ( codings [ ";"
"q" "=" qvalue ] ).
And if you see the definition of '#', you can find out that null element
can't be counted, and this means you can't just leave a blank after
Accept-Encoding: .
But in the given example, there exists a blank space and this is considered
as a correct one.
The second error is at the last line. Right after the semi-colon, there
can't be a space(SP) by definition, but there actually is in the example.
Errata ID: 892
Status: Held for Document Update
Type: Editorial
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
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
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: 2301
Status: Rejected
Type: Technical
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.