The errata formerly maintained here have been incorporated into the working drafts of the IETF HTTP bis Working Group. This page was maintained by Scott Lawrence, but no further input to it is being accepted - use the discussion list for the working group above.
This page collects the known errata in the two RFCs that specify HTTP/1.1:
ietf-http-wg@w3.org
ietf-http-wg-request@w3.org
with just the word 'subscribe' in the body
The links to specification sections below go to HTML (and therefor unofficial) versions of the specs produced by Chris Newman, then at Innosoft. The corporate successor to Innosoft does not appear to have maintained that archive, but it can still be found at http://www.apps.ietf.org/rfc/ .
[Archive Mail]
In general, quoted string literals in the spec are defined to be case insensitive, but the HTTP Version token should be case sensitive. In section 3.1 it says:
The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
It should add:
The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message.HTTP-Version is case-sensitive.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
[Archive Mail]
In the rules for comparison of URIs [section 3.2.3], it says:
Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
but RFC 2396 has no definition of a character set called "unsafe".
The paragraph should read:
Characters other than those in the "reserved" set (see
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
This was an historical artifact. An earlier HTTP draft had defined a set of 'unsafe' characters, but they were characters that were not valid in a URI, so making a special case in the comparison rule was not needed.
[Archive Mail]
In the description of chunked transfer encoding [section 3.6.1], the syntax for a chunk is given as:
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
The accompanying text defines chunk-size incorrectly as:
The chunk-size field is a string of hex digits indicating the size of the chunk.
This doesn't correctly describe what octets the chunk-size field is counting; it should be:
The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets.
(in other words, the chunk length does not include the count of the octets in the chunk header and trailer).
[Archive Mail]
In the discussion of how to determine the message length [section 4.4], the fourth possibility somehow lost a number of characters. The spec 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 read:
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.