RFC2616bis Issues

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

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.

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

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.

In the description of the Server header [section 14.38], the Via field is described as a SHOULD:

If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (as described in section 14.45).

It should be a MUST:

If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it MUST include a Via field (as described in section 14.45).

The requirement is stated correctly in the description of the Via header, [section 14.45].

In the description of the Location header [section 14.30], the ABNF for the Location header is given as:

    Location       = "Location" ":" absoluteURI

This and the accompanying text are incorrect because the definition of 'absoluteURI', given in RFC 2396 does not include fragment identifiers. The correct syntax for the Location header is:

    Location       = "Location" ":" absoluteURI [ "#" fragment ]

There are circumstances in which a fragment identifier in a Location URL would not be appropriate:

• With a 201 Created response, because in this usage the Location header specifies the URL for the entire created resource.
• With a 300 Multiple Choices, since the choice decision is intended to be made on resource characteristics and not fragment characteristics.
• With 305 Use Proxy.

At present, the behavior in the case where there was a fragment with the original URI, e.g.: http://host1.example.com/resource1#fragment1 where /resource1 redirects to http://host2.example.com/resource2#fragment2 is 'fragment1' discarded? Do you find fragment2 and then find fragment1 within it? We don't have fragment combination rules.

In the references [section 17], markers for the editors notes got left in; they are meaningless and can be safely ignored. They are:

    [jg639] [jg640] [jg641] [jg642] [jg643] [jg644] [jg645] [jg646] [jg647]

In the description of Internet Media Types in [section 3.7], the wrong RFC is cited for the media type registration process. The text says:

Media-type values are registered with the Internet Assigned Number Authority (IANA [19]). The media type registration process is outlined in RFC 4288 [17]. Use of non-registered media types is discouraged.

But should be:

Media-type values are registered with the Internet Assigned Number Authority (IANA [19]). The media type registration process is outlined in RFC 2048 [17]. Use of non-registered media types is discouraged.

The cited Reference [section 17] is also incorrect; it is:

    [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
    November 1996.

(oddly, the date cited is wrong for that RFC and correct for the right one) It should be:

    [17] Freed, N., Klensin, J., and Postel, J., "Mulitpurpose Internet Mail
        Extensions (MIME) Part Four: Registration Procedure", RFC 2048,
    November 1996.

In [section 13.5.1], which describes End-to-End and Hop-by-Hop headers, the text says:

    The following HTTP/1.1 headers are hop-by-hop headers:
    
    - Connection
    - Keep-Alive
    - Proxy-Authenticate
    - Proxy-Authorization
    - TE
    - Trailers
    - Transfer-Encoding
    - Upgrade

But the correct header name is 'Trailer' (no 's'):

    The following HTTP/1.1 headers are hop-by-hop headers:
    
    - Connection
    - Keep-Alive
    - Proxy-Authenticate
    - Proxy-Authorization
    - TE
    - Trailer
    - Transfer-Encoding
    - Upgrade

Section 10.3.2 (301 Moved Permanently) contains the paragraph

    If the 301 status code is received in response to a request other
        than GET or HEAD, the user agent MUST NOT automatically redirect the
    request unless it can be confirmed by the user, since this might
    change the conditions under which the request was issued.

which fails to consider that there are many other request methods that are safe to automatically redirect, and further that the user agent is able to make that determination based on the request method semantics. In particular, the OPTIONS method is always safe to automatically redirect. Unfortunately, the paragraph was written long before there was OPTIONS, and was never updated to reflect the extensibility of methods. The same problem paragraph is found in sections 10.3.3 and 10.3.8.

The above should be replaced with

    If the 301 status code is received in response to a request method
        that is known to be "safe", as defined in section 9.1.1, then the
        request MAY be automatically redirected by the user agent without
        confirmation.  Otherwise, the user agent MUST NOT automatically
    redirect the request unless it is confirmed by the user, since the
    new URI might change the conditions under which the request was issued.

along with similar changes for sections 10.3.3 and 10.3.8. It would also be helpful for each of the method definition sections to specifically define whether or not the method is safe. OPTIONS, GET, and HEAD are all safe in RFC 2616. HTTP extensions like WebDAV define additional safe methods.

Section 5.1.2 defines a Request-URI as:

    Request-URI    = "*" | absoluteURI | abs_path | authority

where it gets abs_path by reference to RFC 2396; however, the abs_path in RFC 2396 doesn't include a possible query part:

    hier_part     = ( net_path | abs_path ) [ "?" query ]
    net_path      = "//" authority [ abs_path ]
    abs_path      = "/"  path_segments

The definition of Request-URI should be:

    Request-URI   = "*" | absoluteURI | abs_path [ "?" query ] | authority

There is some ambiguity in Section13.10 as to how the word 'only' binds here:

In order to prevent denial of service attacks, an invalidation based on the URI in a Location or Content-Location header MUST only be performed if the host part is the same as in the Request-URI.

The following clarification, along with separating the clause explaining the rationale for the rule, is suggested:

An invalidation based on the URI in a Location or Content-Location header MUST NOT be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service attacks.

In order to clarify when charset values may be quoted, the following is added to section 3.4:

HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token) and as the value of a parameter in a Content-type header (within a request or response), in which case the parameter value of the charset parameter may be quoted.

Section 14.10 says:

HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.

it should say:

An HTTP/1.1 client that does not support persistent connections MUST include the "close" connection option in every request message.

An HTTP/1.1 server that does not support persistent connections MUST include the "close" connection option in every response message that does not have a 1xx (informational) status code.

The "identity" transfer coding was removed, but some references to it were not.

In section 3.6, remove reference to non-existant section

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

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), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).

In section 4.4 remove 'other than identity' for Transfer-Encoding case since identity is not a valid value.

2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.

2.If a Transfer-Encoding header field (section 14.41) is present, then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.

Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored.

Messages MUST NOT include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length MUST be ignored.

In section 19.4.5 remove 'identity' CTE.

HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client.

HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.

The description of POST was broadened over time, and is not clear. It is clarified by the following changes in Section 9.5:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.

The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed by the resource identified by the Request-URI in the Request-Line.

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.

In Section 10.2.7 the spec implies that it may be ok to use a weak cache validator in a 206 response. The correct language is more restrictive.

If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.

If the 206 response is the result of an If-Range request, the response SHOULD NOT include other entity-headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.

In section 14.3, the definition of Accept-Encoding is given as follows:

Accept-Encoding  = "Accept-Encoding" ":"
1#( codings [ ";" "q" "=" qvalue ] )

This definition implies that there must be at least one non-null codings. However, just below this definition, one of the examples given has an empty Accept-Encoding field-value:

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

Furthermore, the fourth rule for testing whether a content-coding is acceptable mentions the possibility that the field-value may be empty.

In section 3.2.2, http_URL is defined as follows:

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

However, RFC 2616 does not contain a rule called "query". I assume this is meant to be the same "query" that is defined in RFC 2396, since section 3.2.1 incorporates "URI-reference", "absoluteURI", "relativeURI", "port", "host", "abs_path", "rel_path", and "authority" from that specification (but "query" is missing from this list).

RFC 2616 reads:

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

I wrote a regular expression based on the RFC 2616 definition, and that allows "foo\" as a quoted-string. That's not intended, is it?