RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

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.

Report New Errata