RFC2616bis Issues

$Date: 2007/12/22 23:18:50 $

$Revision: 1.36 $

This is the old issues list pre-WG; please see the new WG issues list.

Statistics

RFC2616 total
active 60 60
closed 34 34
total 94 94

open issues summary

id title target type
i19 Bodies on GET (and other) requests RFC2616 design
i20 Default charsets for text media types RFC2616 design
i21 PUT side effects RFC2616 design
i22 ETag (and other metadata) in status messages RFC2616 design
i23 no-store invalidation RFC2616 design
i24 Requiring Allow in 405 responses RFC2616 design
i27 PUT idempotency RFC2616 design
i28 Connection closing RFC2616 design
i29 Age calculation RFC2616 design
i30 Header LWS RFC2616 design
i32 OPTIONS * RFC2616 design
i33 TRACE security considerations RFC2616 design
i34 Updated reference for URIs RFC2616 design
i35 Split Normative and Informative references RFC2616 design
i37 Vary and non-existant headers RFC2616 design
i38 Mismatched Vary RFC2616 design
i39 ETag uniqueness RFC2616 design
i41 Security Considerations RFC2616 design
i43 Fragment combination / precedence during redirects RFC2616 design
i51 HTTP-date vs. rfc1123-date RFC2616 design
i54 Definition of 1xx Warn-Codes RFC2616 design
i58 What identifies an HTTP resource RFC2616 design
i61 Redirection vs. Location RFC2616 design
i63 Header length limit with encoded words RFC2616 design
i64 WS in quoted-pair RFC2616 design
i69 Clarify "Requested Variant" RFC2616 design
i70 Cacheability of 303 response RFC2616 design
i71 Examples for ETag matching RFC2616 design
i73 Clarification of the term "deflate" RFC2616 design
i74 Character encodings for Headers RFC2616 design
i75 RFC2145 Normative RFC2616 design
i76 Deprecate 305 Use Proxy RFC2616 design
i77 Line folding RFC2616 design
i78 Relationship between 401, Authorization and WWW-Authenticate RFC2616 design
i79 Content-* vs. PUT RFC2616 design
i80 Content-Location isn't special RFC2616 design
i81 Content Negotiation for media types RFC2616 design
i83 OPTIONS * and proxies RFC2616 design
i85 Custom Ranges RFC2616 design
i88 205 Bodies RFC2616 design
i89 If-* and entities RFC2616 design
i90 Delimiting messages with multipart/byteranges RFC2616 design
i93 Repeating single-value headers RFC2616 design
i94 Reason-Phrase BNF RFC2616 design
i13 Updated reference for language tags RFC2616 editorial
i36 ABNF RFC2616 editorial
i40 Header registration RFC2616 editorial
i50 Misc. Typos RFC2616 editorial
i52 Sort 1.3 Terminology RFC2616 editorial
i53 Allow is not in 13.5.2 RFC2616 editorial
i55 Updating to RFC4288 RFC2616 editorial
i56 6.1.1 can be misread as a complete list RFC2616 editorial
i57 Status Code and Reason Phrase RFC2616 editorial
i59 Status Code Registry RFC2616 editorial
i60 13.5.1 and 13.5.2 RFC2616 editorial
i67 Quoting Charsets RFC2616 editorial
i72 Request Method Registry RFC2616 editorial
i82 rel_path not used RFC2616 editorial
i91 Duplicate Host header requirements RFC2616 editorial
i92 Empty Host Headers - BNF RFC2616 editorial

closed issues summary

id title target type draft
i1 HTTP Version should be case sensitive RFC2616 design 01
i3 Chunk Size Definition RFC2616 design 01
i5 Via is a MUST RFC2616 design 01
i6 Fragments allowed in Location RFC2616 design 01
i10 Safe Methods vs Redirection RFC2616 design 01
i11 URI includes query RFC2616 design 01
i12 Invalidation after Update or Delete RFC2616 design 01
i14 Clarification regarding quoting of charset values RFC2616 design 01
i15 No close on 1xx responses RFC2616 design 01
i17 Revise description of the POST method RFC2616 design 01
i18 Cache validators in 206 responses RFC2616 design 01
i25 Accept-Encoding BNF RFC2616 design 04
i31 qdtext BNF RFC2616 design 04
i62 Whitespace in quoted-pair RFC2616 design
i2 'unsafe' characters RFC2616 editorial 01
i4 Message Length RFC2616 editorial 01
i7 Editors Notes RFC2616 editorial 01
i8 Media type registrations RFC2616 editorial 04
i9 Trailer RFC2616 editorial 01
i16 Remove 'identity' token references RFC2616 editorial 01
i26 Import query BNF RFC2616 editorial 04
i42 RFC2606 compliance RFC2616 editorial 02
i44 Unneeded references RFC2616 editorial 04
i45 RFC977 reference RFC2616 editorial 03
i46 references to RFC1700 RFC2616 editorial 03
i47 inconsistency in date format explanation RFC2616 editorial 04
i48 Date reference typo RFC2616 editorial 03
i49 Connection header text RFC2616 editorial 03
i65 Informative references RFC2616 editorial 04
i66 ISO-8859-1 Reference RFC2616 editorial 04
i68 Encoding References Normative RFC2616 editorial 04
i84 Redundant cross-references RFC2616 editorial 04
i86 Normative up-to-date references RFC2616 editorial 04
i87 typo in 13.2.2 RFC2616 editorial 04

Detailed Listing

i1 HTTP Version should be case sensitive RFC2616 - design - closed
Description

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
Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i2 'unsafe' characters RFC2616 - editorial - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i3 Chunk Size Definition RFC2616 - design - closed
Description

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

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i4 Message Length RFC2616 - editorial - closed
Description

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.
Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i5 Via is a MUST RFC2616 - design - closed
Description

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

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i6 Fragments allowed in Location RFC2616 - design - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i7 Editors Notes RFC2616 - editorial - closed
Description

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]
Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i8 Media type registrations RFC2616 - editorial - closed
Description

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.
Origin
(source)
Resolution (incorporated: 04)
Updated.
i9 Trailer RFC2616 - editorial - closed
Description

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
Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i10 Safe Methods vs Redirection RFC2616 - design - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i11 URI includes query RFC2616 - design - closed
Description

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
Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i12 Invalidation after Update or Delete RFC2616 - design - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i13 Updated reference for language tags RFC2616 - editorial - active
Description

RFC 1766, which is referenced by RFC 2616 section 3.10 as the source for its definition of language tags has a BNF has been updated by RFC3066 (a BCP).

RFC 3066 defines these as:

    Language-Tag = Primary-subtag *( "-" Subtag )
    Primary-subtag = 1*8ALPHA
    Subtag = 1*8(ALPHA / DIGIT)

HTTP/1.1 RFC 2616 defines these as:

    language-tag  = primary-tag *( "-" subtag )
    primary-tag   = 1*8ALPHA
    subtag        = 1*8ALPHA

In the meantime, RFC3066 has been obsoleted by RFC4646, and the original grammar production defining subtags seems to be gone:

     
Language-Tag  = langtag
/ privateuse             ; private use tag
/ grandfathered          ; grandfathered registrations

langtag       = (language
["-" script]
["-" region]
*("-" variant)
*("-" extension)
["-" privateuse])

language      = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code
/ 4ALPHA                 ; reserved for future use
/ 5*8ALPHA               ; registered language subtag

extlang       = *3("-" 3ALPHA)         ; reserved for future use

script        = 4ALPHA                 ; ISO 15924 code

region        = 2ALPHA                 ; ISO 3166 code
/ 3DIGIT                 ; UN M.49 code

variant       = 5*8alphanum            ; registered variants
/ (DIGIT 3alphanum)

extension     = singleton 1*("-" (2*8alphanum))

singleton     = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
; Single letters: x/X is reserved for private use

privateuse    = ("x"/"X") 1*("-" (1*8alphanum))

grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum))
; grandfathered registration
; Note: i is the only singleton
; that starts a grandfathered tag

alphanum      = (ALPHA / DIGIT)       ; letters and numbers

So shouldn't RFC2616 (Section 3.10) stop defining these things, and just normatively refer to RFC4626 for the definition of "Language-Tag"?

i14 Clarification regarding quoting of charset values RFC2616 - design - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i15 No close on 1xx responses RFC2616 - design - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i16 Remove 'identity' token references RFC2616 - editorial - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i17 Revise description of the POST method RFC2616 - design - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i18 Cache validators in 206 responses RFC2616 - design - closed
Description

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.

Origin
(source)
Resolution (incorporated: 01)
Incorporated from draft-gettys.
i19 Bodies on GET (and other) requests RFC2616 - design - active
Description
Is a request body allowed on GET? Other requests?
Origin
(source)
i20 Default charsets for text media types RFC2616 - design - active
Description

2616 Section 3.7.1 states;

When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP.

However, many, if not all, of the text/* media types define their own defaults; text/plain (RFC2046), for example, defaults to ASCII, as does text/xml (RFC3023).

How do these format-specific defaults interact with HTTP's default? Is HTTP really overriding them?

I'm far from the first to be confused by this text, and I'm sure it's been asked before, but I haven't been able to find a definitive answer. If errata are still being considered, perhaps removing/ modifying this line would be a good start...

Origin
(source)
i21 PUT side effects RFC2616 - design - active
Description

2616 specifically allows PUT to have side effects;

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

HTTP/1.1 does not define how a PUT method affects the state of an origin server.

and it also says (in the context of PUT)

If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response.

So, if I PUT something to /foo, and it has the side effect if creating /foo;2006-04-03, is the response required to be a 201 Created?

I.e., read literally, the above requirement requires a 201 Created when PUT results in *any* resource being created -- even as a side effect.

This is IMO unnecessarily constraining, and should be relaxed; e.g., changed to something like

Origin
(source)
Proposal 1

"If a new resource is created at the Request-URI, the origin server MUST inform the user agent via the 201 (Created) response."

i22 ETag (and other metadata) in status messages RFC2616 - design - active
Description

It's not clear what the headers in a response to a PUT apply to; for example, does an ETag apply to that response, or the response that would be returned upon a GET?

The same questions apply in other cases where the response serves as a status message.

Proposal 1
i23 no-store invalidation RFC2616 - design - active
Description

Responses to HTTP requests with "Cache-control: no-store" are not cachable. Recently, we came across a cache that does not cache responses to no-store requests but also does not invalidate an older cached entity with the same URL. When future requests stop using no-store, the old cached entity is served.

For example, the following happens in our test case:

  1. Client requests an entity A without using no-store.
  2. Cache proxies the transaction and caches the response (entity A).
  3. Client requests the same entity A using "Cache-control: no-store".
  4. Cache proxies the transaction and does NOT cache the response.
  5. Client requests the same entity A again, without using no-store.
  6. Cache serves the "old" entity A cached in step #2 above.

Does the cache violate the intent of RFC 2616 in step #6? If yes, should that intent be made explicit (I cannot find any explicit rules prohibiting the above behavior).

Origin
(source)
i24 Requiring Allow in 405 responses RFC2616 - design - active
Description

In RFC 2616, section 10.4.6 405 Method Not Allowed:

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.

which has the effect of requiring that a server advertise all methods to a resource. In some cases, method implementation is implemented across several (extensible) parts of a server and thus not known. In other cases, it may not be prudent to tell an unauthenticated client all of the methods that might be available to other clients.

Origin
(source)
Proposal 1
Change the MUST to MAY in 10.4.6.
i25 Accept-Encoding BNF RFC2616 - design - closed
Description

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.

Origin
(source)
Proposal 1

The definition for Accept-Encoding should be revised:

Accept-Encoding  = "Accept-Encoding" ":"
                #( codings [ ";" "q" "=" qvalue ] )
Resolution (incorporated: 04)
Proposal 1.
i26 Import query BNF RFC2616 - editorial - closed
Description

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

Origin
(source)
Proposal 1
Add "query" to the list of imported rules in section 3.2.1.
Resolution (incorporated: 04)
Proposal 1.
i27 PUT idempotency RFC2616 - design - active
Description

It *appears* that RFC3253 changes the idempotency of PUT; is this allowed? RFC3253 doesn't update or obsolete 2616...

I can see a situation where a 3253-naive client decides to retry a timed-out PUT (after all, it's idempotent) and gets some side effects it didn't bargain for.

Origin
(source)
i28 Connection closing RFC2616 - design - active
Description

The phrase "unless the message is terminated by closing the connection" in Section 4.4 is unnecessary.

Section 3.6 uses the same phrase; it is a little confusing. In 4.4 you could almost read it to mean that presence of "Connection: close" would mean that a T-E header should be ignored, which is presumably not the intent (and certainly not the practice).

Origin
(source)
i29 Age calculation RFC2616 - design - active
Description

RFC 2616 says:

Because the request that resulted in the returned Age value must have been initiated prior to that Age value's generation, we can correct for delays imposed by the network by recording the time at which the request was initiated. Then, when an Age value is received, it MUST be interpreted relative to the time the request was initiated... So, we compute:

corrected_initial_age = corrected_received_age + (now - request_time)

I suspect the formula does not match the true intent of the RFC authors. I believe that corrected_initial_age formula counts server-to-client delays twice. It does that because the corrected_received_age component already accounts for one server-to-client delay. Here is an annotated definition from the RFC:

corrected_received_age = max(
now - date_value, # trust the clock (includes server-to-client delay!)
age_value)        # all-HTTP/1.1 paths (no server-to-client delay)

I think it is possible to fix the corrected_initial_age formula to match the intent (note this is the *initial* not *received* age):

corrected_initial_age = max(
now - date_value,                # trust the clock (includes delays)
age_value + now - request_time)  # trust Age, add network delays

There is no need for corrected_received_age.

Moreover, it looks ALL the formulas computing current_age go away with the above new corrected_initial_age definition as long as "now" is still defined as "the current time" (i.e., the time when current_age is calculated):

current_age = corrected_initial_age

So, we end up with a single formula for all cases and all times:

current_age = max(now - date_value, age_value + now - request_time) = = now - min(date_value, request_time - age_value)

It even has a clear physical meaning -- the min() part is the conservative estimate of object creation time.

Origin
(source)
Proposal 1
creation_time = min(date_value, request_time - age_value);
current_age = now - creation_time;
i30 Header LWS RFC2616 - design - active
Description
  1. Is LWS permitted between the field-name and colon?

    The grammar of RFC 2616 suggests that it is, because ":" is a separator character, and thus the rule for implied LWS between a token and a separator applies.

    The wording suggests otherwise, although it is not explicit:

    Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of LWS, though a single SP is preferred.

    The wording explicit states LWS is permitted after the colon, suggesting that the intention is that it's not permitted before the colon.

    Many authors have taken that interpretion, resulting in most of the servers I looked at not accepting LWS before the colon. (They should probably reject the request, but all of them treat it as an unknown header name including a space in the name token).

    Apache now, and Mozilla, accept LWS at that position.

  2. What about LWS before the field-name?

    At first sight, this doesn't make sense: LWS at the start of the line indicates folding. However, all implementations I looked at accept a line beginning with LWS immediately after the Request-Line or Status-Line. Some of them treat the initial LWS as part of the field-name (they don't enforce the limited character range of tokens), or they skip the LWS.

    Apache doesn't look for and ignore LWS prior to the first field-name. Neither do Squid, thttpd or lighttpd. Mozilla and phttpd do.

    Technically, the grammar disallows LWS before the field-name: Implied LWS is only implied _between_ words and separators.

Both of these inconsistencies between programs, and also that lone CR is treated as LWS by some and not others, lead to potential security holes due to non-compliant messages that claim to be HTTP/1.1. Although it isn't the standard's role to state how a program should respond to every kind of invalid message, it would be good to clarify these points because they do have security implications (which was Apache's stated reason for their change):

  1. Whether LWS is actually permitted between the field-name and colon. (Grammar says it is; wording suggests it isn't. Implementations vary).
  2. Whether LWS is actually permitted before the field-name. (Grammar says it isn't. Implementations vary).
  3. That lone CR in a line is explicitly not allowed and SHOULD (or MUST?) be rejected, for the specific reason that implementations vary as to whether it is treated as LWS, which has security implications for programs which must match on the field-name.
  4. That invalid field-names (such as containing control characters or LWS) SHOULD (or MUST?) be rejected.
Origin
(source)
i31 qdtext BNF RFC2616 - design - closed
Description

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?

Origin
(source)
Proposal 1

I think the qdtext syntax should say this instead:

qdtext         = <any TEXT except <"> and "\">

(It might also want to say "excluding" instead of "except", for consistency with ctext a few lines earlier).

Resolution (incorporated: 04)
Proposal 1.
i32 OPTIONS * RFC2616 - design - active
Description

I'd like to see a clarification about what clients can expect upon OPTIONS *. In particular, can they expect to find out about *any* method name supported on that server? I'm asking because this doesn't seem to be the case for at least two major server bases, being:

  • Apache (for instance, additional method names supported by mod_dav aren't listed) and
  • generic Java servlet engines (servlet API does not support delegation of requests against "*" to all installed web applications)
Origin
(source)
i33 TRACE security considerations RFC2616 - design - active
Description

There is an HTTP-related security violation approach found/researched by White Hat Security:

PR: http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt
Details: http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf

I bet many of you have seen the related advisories/PR. For those who have not, here is the gist:

Modern browsers usually do not allow scripts embedded in HTML to access cookies and authentication information exchanged between HTTP client and server. However, a script can get access to that info by sending a simple HTTP TRACE request to the originating (innocent) server. The user agent will auto-include current authentication info in such request. The server will echo all the authentication information back, for script to read and [mis]use. Apparently, sending an HTTP request is possible via many scripting methods like ActiveX. See the URL above for details.

With numerous XSS (cross-site-scripting) vulnerabilities in user agents, this seems like a real and nasty problem. TRACE method support is optional per RFC 2616, but many popular servers support it. White Hat Security advises server administrators to disable support for TRACE.

Origin
(source)
i34 Updated reference for URIs RFC2616 - design - active
Description

RFC2616 refers to RFC2396, RFC1630, RFC1738, and RFC1808, all of which have been obsoleted by RFC3986.

If the reference is changed, it will important to remember to make a decision about the "mark" production in the former (which are unreserved characters) which have been moved to have reserved status in the latter.

By referencing 2396, HTTP allows these characters unescaped in path segments, etc. If 3986 is referenced as-is, they will be effectively disallowed, thereby effectively making a number of existing HTTP URIs invalid.

This includes the exclamation mark ("!"), asterisk ("*"), single-quote ("'"), and open and close parentheses ("(" and ")").

Origin
(source)
i35 Split Normative and Informative references RFC2616 - design - active
Description
References are now required to be split into "Normative" and "Informative".
i36 ABNF RFC2616 - editorial - active
Description
Update BNF to RFC4234.
i37 Vary and non-existant headers RFC2616 - design - active
Description
  • When an origin server selects the response by looking at a request header, and the header does not exist, is it correct for the server to add the name of that header to Vary?

    For example, suppose a server's logic is like this pseudo-code:

    reponse_headers (Vary) = "Accept-Language"
    
    IF request_headers (Accept-Language) contains "ja" THEN
    serve the japanese page
    ELSE 
    serve the english page
    ENDIF

    What is the correct HTTP response when the request doesn't have an Accept-Language header?

    I would guess that the correct response is to "include Vary: Accept-Language", but that begs the next question:

  • How should a cache treat missing requests headers which are mentioned in Vary, when deciding if a stored entity matches a request?

    • a. If the stored entity was requested _without_ the header mentioned in Vary, and the new request is also _without_ the header, does the stored entity match? (This would come from scenario 1 above).
    • b. If the stored entity was requested _without_ the header mentioned in Vary, and the new request is _with_ the header, does the stored entity match?
    • c. If the stored entity was requested _with_ the header mentioned in Vary, and the new request is _without_ the header, does the stored entity match?

    I would imagine that in case a, the entity matches, and in cases b and c, the entity doesn't match and must be revalidated.

    But the language of RFC 2616 is a unclear:

    When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request.

    Can the selecting request-headers "match" if they are absent? What about case a?

    The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2.

    Is this supposed to mean that an absent header is equivalent to an empty header, or that an absent header is semantically a distinct value from an empty header, or that an absent header is not considered at all in the decision, or that an absent header cannot be matched even with an absent header in the original request for the cached entity?

  • Does this mean that server code which inspects a header value, and finds the header missing, should look like this instead?

    IF exists request_headers (Accept-Language) THEN
    reponse_headers (Vary) = "Accept-Language"
    ELSE
    response_headers (Vary) = "*"
    ENDIF
    
    IF request_headers (Accept-Language) contains "ja" THEN
    serve the japanese page
    ELSE 
    serve the english page
    ENDIF

    The conservative thing to do is to disable cacheing when an examined request-header is absent, but that seems excessively pessimistic.

Origin
(source)
Proposal 1
remove "present"
i38 Mismatched Vary RFC2616 - design - active
Description

When one cached variant has one Vary header, and then another variant is received with a different Vary header. Lets say the first has

Vary: Accept-Language

and the second

Vary: Accept-Encoding

what is the appropriate behaviour for a cache?

Origin
(source)
i39 ETag uniqueness RFC2616 - design - active
Description

From experience I think it's also worthwhile to further stress the importance of ETag uniqueness among variants of a URI. Very few implementations get this part correct. In fact most major web servers have issues here...

Some even strongly believe that entities with different Content-Encoding is the same entity, arguing that since most encoding (at least the standardized ones) can be converted to the same identity encoding so they are in fact the same entity and should have the same strong ETag.

Origin
(source)
i40 Header registration RFC2616 - editorial - active
Description
A revision of RFC2616 should mention BCP 90 (Registration Procedures for Message Header Fields) and should take over as the authoritative reference for the headers it contains.
i41 Security Considerations RFC2616 - design - active
Description
What work needs to be done to the Security Considerations section of RFC2616 to allow publication of a revision? E.g., does HTTP need to specify a Mandatory To Implement mechanism?
i42 RFC2606 compliance RFC2616 - editorial - closed
Description
Make sure that domain names in examples use names reserved for that purpose (see RFC2606).
Resolution (incorporated: 01)
Resolution (incorporated: 02)
i43 Fragment combination / precedence during redirects RFC2616 - design - active
Description
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.
Origin
(source)
i44 Unneeded references RFC2616 - editorial - closed
Description
RFC1866 and RFC2069 aren't mentioned anywhere in the spec. These references probably are leftovers from revising RFC2068.
Origin
(source)
Proposal 1
Remove the references.
Resolution (incorporated: 04)
Proposal 1.
i45 RFC977 reference RFC2616 - editorial - closed
Description
classify RFC977 reference as "informative", and update to RFC3977
Origin
(source)
Resolution (incorporated: 03)
Fixed.
i46 references to RFC1700 RFC2616 - editorial - closed
Description

RFC1700 ("ASSIGNED NUMBERS") has been obsoleted by RFC3232 ("Assigned Numbers: RFC 1700 is Replaced by an On-line Database").

draft-gettys-http-v11-spec-rev-00 just updates the reference, which I think is a bug.

In fact, RFC2616 refers to RCF1700:

  1. for the definition of the default TCP port,
  2. for a reference to the character set registry, and
  3. for a reference to the media type registry.
Origin
(source)
Proposal 1

For each of the above references:

  1. Replace reference with in-lined URL of the IANA port registry,
  2. Replace the first reference with the in-lined URL of the IANA character set registry, and drop the second one, and
  3. Drop the reference, as the next sentence refers to the Media Type Registration Process anyway.
Resolution (incorporated: 03)
Proposal 1.
i47 inconsistency in date format explanation RFC2616 - editorial - closed
Description

In Section 3.3.1, RFC2616 says:

"The second format is in common use, but is based on the obsolete RFC 850 [12] date format and lacks a four-digit year."

However, [12] refers to RFC1036, which obsoletes RFC850.

Origin
(source)
Proposal 1
"The second format is in common use, but is based on the obsolete RFC1036 date format [12] and lacks a four-digit year."
Resolution (incorporated: 03)
Proposal 1.
Resolution (incorporated: 04)
(Fixes proposed by Roy Fielding applied).
i48 Date reference typo RFC2616 - editorial - closed
Description
Currently, RFC2616 says about the date format for the "Date" header: "The field value is an HTTP-date, as described in section 3.3.1; it MUST be sent in RFC 1123 [8]-date format."
Origin
(source)
Proposal 1
"The field value is an HTTP-date, as described in section 3.3.1; it MUST be sent in rfc1123-date [8] format."
Resolution (incorporated: 03)
Proposal 1.
i49 Connection header text RFC2616 - editorial - closed
Description

Section 13.5.1 currently ends with:

Other hop-by-hop headers MUST be listed in a Connection header, (section 14.10) to be introduced into HTTP/1.1 (or later).

Origin
(source)
Proposal 1
Other hop-by-hop headers MUST be listed in a Connection header (Section 14.10).
Resolution (incorporated: 03)
Proposal 1.
i50 Misc. Typos RFC2616 - editorial - active
Description
  1. Section 7.1, page 42: Some of this metainformation is "OPTIONAL "; some might be "REQUIRED " by portions of this specification.
  2. Section 13.13, page 99: Even though sometimes such resources ought not to be cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms.
  3. Section 14.18, page 124: The field value is an HTTP-date, as described in section 3.3.1; it MUST be sent in the RFC 1123 [8] -  date format.
  4. Section 14.23, page 129: A client MUST include a Host header field in all HTTP/1.1 request messages  .
  5. Section 14.32, page 137: Note: because the meaning of "Pragma: no-cache " as a response   -header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response .
  6. Section 15.6, page 155: HTTP/1.1 . does not provide a method for a server to direct clients to discard these cached credentials.
  7. Section 2.1, page 15: At least one delimiter (LWS and/or
     separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.
Origin
(source)
i51 HTTP-date vs. rfc1123-date RFC2616 - design - active
Description
Should rfc1123-date BNF be used where the specification calls for something to be a HTTP-date, but only the RFC1123 form? Should separate rules for producing and consuming dates be specified?
Origin
(source)
i52 Sort 1.3 Terminology RFC2616 - editorial - active
Description
It's irritating to try and look up definitions in section 1.3. IMHO, the entries really should be sorted alphabetically, despite the fact that the terms have dependencies on one another.
Origin
(source)
i53 Allow is not in 13.5.2 RFC2616 - editorial - active
Description

Section 14.7 states:

"A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other means of communicating with the origin server."

However, section 13.5.2 (Non-modifiable Headers) makes no mention of Allow. This seems like an error, but I'm not entirely sure what the fix should be -- remove 13.5.2 and push the (not-)modifiable information in the definition of the respective headers, or to maintain 13.5.2 in parallel with all of the header definitions, or to push all the information out of the header definitions into 13.5.2.

The easy fix for now would be to just make a mention of Allow in 13.5.2.

Additionally, Server should also be included.

Origin
(source)
i54 Definition of 1xx Warn-Codes RFC2616 - design - active
Description

The offending part of section 13.1.2 (Warnings, page 77) reads:

1xx Warnings that describe the freshness or revalidation status of the response, and so MUST be deleted after a successful revalidation. 1XX [sic] warn-codes MAY be generated by a cache only when validating a cached entry. It MUST NOT be generated by clients.

The problems, in order from simplest to the most complex:

  1. 1XX should be 1xx (or vice-versa) everywhere.
  2. The use of MAY in the offending part of 13.1.2 conflicts with the MUST requirements in section 14.46 and the definition of MAY in BCP14.
  3. One would think that proxies could include caches (though I have yet to find where this is permitted with a true BCP14 MAY). However, the wording in the offending part of 13.1.2 makes it impossible to satisfy the requirements of a cache and the requirements of a client (and, by extension, proxy) simultaneously. A cache is not an independent program; it is part of a program (as per the 1.3 definition). A client is a program, and it can contain a cache (again, from 1.3), but this limits the cache's behavior to the set intersection of allowed behaviors for caches and clients (due to how "client" is defined). This leads to a conflict where the cache MUST generate a 1xx code, but a client MUST NOT generate a 1xx code. Thus, we're left having to conclude that caches can exist only as part of independent servers (which have their content pushed to them, or delivered through some out-of-band method).
Origin
(source)
Proposal 1
  1. pick one, and use it everywhere. I'm partial to 1xx myself :).
  2. "1xx warn-codes MUST NOT be added to any messages except cache entries, and MUST NOT be added to cache entries except in response to a validation attempt." (As a side note, a definition of a cache entry would be nice.)
  3. Maybe "Clients that do not incorporate a cache MUST NOT generate 1xx warn-codes", but I'm not sure what problem the original clause was trying to prevent. The proposed fix in (2) above might cover everything, allowing the deletion of this sentence altogether.
i55 Updating to RFC4288 RFC2616 - editorial - active
Description
The update from RFC2048 to RFC4288 requires minor modifications for the media type registrations for "message/http", "application/http" and "multipart/byteranges".
Origin
(source)
i56 6.1.1 can be misread as a complete list RFC2616 - editorial - active
Description
The second sentence in the first paragraph can on a quick reading be misread as section 10 contains a complete definiton of all possible status codes, where it in reality only has the status codes defined by this RFC.
Origin
(source)
Proposal 1
Change "These codes are fully defined in section 10." Into "The status codes defined by this RFC is fully defined in section 10."
i57 Status Code and Reason Phrase RFC2616 - editorial - active
Description

6.1.1 is apparently a bit too vague about how applications should parse and process the information, making some implementations parse the reason phrase (probably exact matches on the complete status line, not just status code) to determine the outcome.

There should be a SHOULD requirement or equivalent that applications use the status code to determine the status of the response and only process the Reason Phrase as a comment intended for humans.

It's true that later in the same section there is a reverse MAY requirement implying this by saying that the phrases in the rfc is just an example and may be replaced without affecting the protocol, but apparently it's not sufficient for implementers to understand that applications should not decide the outcome based on the reason phrase.

Origin
(source)
Proposal 1

I propose rewording the last sentence of the first paragraph "The client is not required to examine or display the Reason-Phrase." into something like

The client MAY present the Reason Phrase to the user and SHOULD NOT examine the Reason Phrase for other purposes.

or perhaps

The client SHOULD NOT examine the Reason Phrase for other purposes than displaying it to the user.

i58 What identifies an HTTP resource RFC2616 - design - active
Description

3.2.2 really doesn't say what identifies the resource:

"If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (Section 5.1.2)."

But it *does* say what part of the HTTP URL becomes the Request-URI, and that definitively needs to be fixed.

Origin
(source)
Proposal 1

Here's a proposed replacement text:

"The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path plus the optional query parameter (Section 5.1.2)."

i59 Status Code Registry RFC2616 - editorial - active
Description
The IANA status code registry should be referred to.
Origin
(source)
i60 13.5.1 and 13.5.2 RFC2616 - editorial - active
Description
13.5.1 and 13.5.2 describe how proxies should handle headers, even though it's in a section entitled "Caching in HTTP." People have a hard time finding them. Would it be helpful to try to separate out the purely intermediary-related material from section 13 to a more appropriate place (e.g., section 8, or a new section)?
Origin
(source)
i61 Redirection vs. Location RFC2616 - design - active
Description

The definition of the Location header currently says:

"The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. (...)"

The issue is that this can be read as if the "...or identification..." can be read as applying to the "redirect" part.

Origin
(source)
Proposal 1

One simple fix seems to be to swap the two parts of the sentence, as in...:

"The Location response-header field is used for the identification of a new resource or to redirect the recipient to a location other than the Request-URI for completion of the request. (...)"

i62 Whitespace in quoted-pair RFC2616 - design - closed
Description
RFC 2822 updates RFC 822's quoted-pair rule to disallow CR, LF, and NUL. We should probably make the same change.
Origin
(source)
Resolution
Duplicate of i64.
i63 Header length limit with encoded words RFC2616 - design - active
Description

RFC 2616 defines RFC 2047 MIME word encoding for use with certain header values, e.g. if they are defined to contain quoted strings. RFC 2047 states:

While there is no limit to the length of a multiple-line header field, each line of a header field that contains one or more 'encoded-word's is limited to 76 characters.

The length restrictions are included both to ease interoperability through internetwork mail gateways, and to impose a limit on the amount of lookahead a header parser must employ (while looking for a final ?= delimiter) before it can decide whether a token is an "encoded-word" or something else.

It seems to me this provision is not meant to apply to HTTP, and if MIME word encoding is to stay with us in the next HTTP specification, it should state that this line length limit does not apply to HTTP.

Origin
(source)
i64 WS in quoted-pair RFC2616 - design - active
Description

I think quoted-pair is broken too. Merging your fix into RFC2616 gives:

    
quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext         = <any TEXT excluding '"' and '\'>
quoted-pair    = "\" CHAR
CHAR           = <any US-ASCII character (octets 0 - 127)>

but that means you can do this:

    
HTTP/1.1 200 OK
Warning: "Don't misparse \
this: it's really a single header!"

(if the receiving implementation follows the recommendations in 19.3 you need to escape the LF instead of the CR, but it's otherwise the same.)

RFC 2822 updates RFC 822's quoted-pair rule to disallow CR, LF, and NUL. We should probably make the same change.

Origin
(source)
i65 Informative references RFC2616 - editorial - closed
Description

the references below are informative and should be classified as such. In some cases, they need to be updated as well:

Luo1998 ("Tunneling TCP based protocols through Web proxy servers", also update reference to quote the expired Internet Draft properly).

Nie1997 ("Network Performance Effects of HTTP/1.1, CSS1, and PNG").

Pad1995 ("Improving HTTP Latency").

RFC821 (SMTP), also update the reference to RFC2821.

RFC822 ("STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES") -- but add another instance as RFC822ABNF for the cases where the reference if for the ABNF part (these references will later be replaced by references to RFC4234 (see issue abnf)).

RFC959 (FTP).

RFC1036 ("Standard for Interchange of USENET Messages").

RFC1123 ("Requirements for Internet Hosts -- Application and Support") -- it is only used as a background reference for rfc1123-date, which this spec defines itself (note that note this disagrees with draft-gettys-http-v11-spec-rev-00 which made it normative).

RFC1305 ("Network Time Protocol (Version 3)").

RFC1436 (Gopher).

RFC1630 (URI Syntax) -- there'll be a normative reference to a newer spec.

RFC1738 (URL) -- there'll be a normative reference to a newer spec.

RFC1806 ("Communicating Presentation Information in Internet Messages: The Content-Disposition Header").

RFC1808 (Relative Uniform Resource Locators).

RFC1867 ("Form-based File Upload in HTML"), also update the reference to RFC2388 ("Returning Values from Forms: multipart/form-data").

RFC1900 ("Renumbering Needs Work").

RFC1945 (HTTP/1.0).

RFC1950 (ZLIB).

RFC1951 (DEFLATE).

RFC1952 (GZIP).

RFC2026 ("The Internet Standards Process -- Revision 3").

RFC2049 ("Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples").

RFC2068 (HTTP/1.1).

RFC2076 ("Common Internet Message Headers").

RFC2110 (MHTML), also update the reference to RFC2557.

RFC2145 ("Use and Interpretation of HTTP Version Numbers").

RFC2183 ("Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field").

RFC2277 ("IETF Policy on Character Sets and Languages").

RFC2279 (UTF8), also update the reference to RFC3629.

RFC2324 (HTCPCP/1.0).

Spero ("Analysis of HTTP Performance Problems").

Tou1998 ("Analysis of HTTP Performance").

WAIS ("WAIS Interface Protocol Prototype Functional Specification (v1.5)").

Origin
(source)
Resolution (incorporated: 04)
As proposed.
i66 ISO-8859-1 Reference RFC2616 - editorial - closed
Description

we currently have the following reference:

                    
[ISO-8859]
International Organization for Standardization,
"Information technology - 8-bit single byte coded graphic
- character sets", 1987-1990.

Part 1: Latin alphabet No. 1, ISO-8859-1:1987.  Part 2:
Latin alphabet No. 2, ISO-8859-2, 1987.  Part 3: Latin
alphabet No. 3, ISO-8859-3, 1988.  Part 4: Latin alphabet
No. 4, ISO-8859-4, 1988.  Part 5: Latin/Cyrillic alphabet,
ISO-8859-5, 1988.  Part 6: Latin/Arabic alphabet, ISO-
8859-6, 1987.  Part 7: Latin/Greek alphabet, ISO-8859-7,
1987.  Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.

Proposed changes:

  • classify as normative,
  • just cite ISO-8859-1 (the other variants aren't needed by HTTP/1.1),
  • update to latest version.

This would make it:

                    
[ISO-8859-1]
International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998.
Origin
(source)
Resolution (incorporated: 04)
As proposed.
i67 Quoting Charsets RFC2616 - editorial - active
Description

The BNF definition of the "Content-Type" production does not utiilize the "charset" production defined in section 3.4, and therefore an occasional reader of RFC2616 who follows the BNF dependencies, does not necessarily notice section 3.4 and hence arrives at the conclusion that the quoted and unquoted form are both equally ok.

Origin
(source)
Proposal 1
I suggest to fix this by utilizing the "charset" production somewhere in the "Content-Type" production. Maybe at the level of "media-type". In addition, an explicit reference to section 3.4 could be added to the description of Content-Type in section 14.17.
i68 Encoding References Normative RFC2616 - editorial - closed
Description

Classify RFC1950 (ZLIB), RFC1951 (DEFLATE) and RFC1952 (GZIP) as normative (note this disagrees with draft-gettys-http-v11-spec-rev-00 which made it informative).

Origin
(source)
Resolution (incorporated: 04)
As proposed.
i69 Clarify "Requested Variant" RFC2616 - design - active
Description
The spec uses the term "requested variant" in several places (10.2.2 201 Created, 10.2.5 204 No Content, 14.19 ETag, 14.25 If-Modified-Since, 14.28 If-Unmodified-Since). It's quite clear what it means in the context of HEAD/GET, somewhat clear for PUT, but not clear at all for other methods. We really need to clarify this, potentially choosing a different term.
Origin
(source)
i70 Cacheability of 303 response RFC2616 - design - active
Description
Section 10.3.4 says that 303 See Other is not cacheable.
Origin
(source)
Proposal 1

10.3.4. 303 See Other

The server directs the user agent to a different resource, indicated by a URI in the Location header field, that provides an indirect response to the original request. The user agent MAY perform a GET request on the URI in the Location field in order to obtain a representation corresponding to the response, be redirected again, or end with an error status. The Location URI is not a substitute reference for the originally requested resource.

The 303 status is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached independent of the original request.

A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such that the follow-on representation may be useful without implying that that it adequately represents the previously requested resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP and thus entirely determined by the resource owner(s).

A 303 response SHOULD NOT be cached unless it is indicated as cacheable by Cache-Control or Expires header fields. Except for responses to a HEAD request, the entity of a 303 response SHOULD contain a short hypertext note with a hyperlink to the Location URI.

i71 Examples for ETag matching RFC2616 - design - active
Description
People seem to be confused about the weak matching function; we should have examples to illustrate it.
Origin
(source)
Proposal 1
                    +--------+--------+-------------------+-----------------+
                    | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
                    +--------+--------+-------------------+-----------------+
                    | W/"1"  | W/"1"  | no match          | match           |
                    |        |        |                   |                 |
                    | W/"1"  | W/"2"  | no match          | no match        |
                    |        |        |                   |                 |
                    | W/"1"  | "1"    | no match          | match           |
                    |        |        |                   |                 |
                    | "1"    | "1"    | match             | match           |
                    +--------+--------+-------------------+-----------------+
                
i72 Request Method Registry RFC2616 - editorial - active
Description
I see a need for an official HTTP request method registry to be established, preferably maintained by IANA.
Origin
(source)
i73 Clarification of the term "deflate" RFC2616 - design - active
Description

Below is the definition of "deflate" from RFC 2616, section 3.5 "Content Codings"

deflate
The "zlib" format defined in RFC 1950 [31] in combination with the "deflate" compression mechanism described in RFC 1951 [29].

There is ambiguity in that definition because of the inconsistent use of the term "deflate". This has resulted in a long standing confusion about how to implement "deflate" encoding.

There was a time a few years back when most of the high profile browser and some http server implementations incorrectly implemented http "deflate" encoding using RFC 1951 without the RFC 1950 wrapper. Admittedly most, if not all, of the incorrect implementations have now been fixed, but the fix applied recognises the reality that there are incorrect implementations of "deflate" out in the wild. All browsers now seem to be able to cope with "deflate" in both its RFC1950 or RFC1951 incarnations.

So I suggest there are two issues that need to be addressed

  1. The definition of "deflate" needs to be rewritten to remove the ambiguity.
  2. Document the reality that there are incorrect implementations, and recommend that anyone writing a "deflate" decoder should cope with both forms.
Origin
(source)
i74 Character encodings for Headers RFC2616 - design - active
Description
RFC 2616 prescribes that headers containing non-ASCII have to use either iso-8859-1 or RFC 2047. This is unnecessarily complex and not necessarily followed by implementations or by specifications of new headers.
Origin
(source)
i75 RFC2145 Normative RFC2616 - design - active
Description
Should RFC2145 references be normative?
Origin
(source)
i76 Deprecate 305 Use Proxy RFC2616 - design - active
Description

I can't find any browser that supports this.

  • IE 6 silently fails (shows blank page, does not attempt connection to proxy).
  • FF 2 silently fails (shows blank page, does not attempt connection to proxy).
  • Opera displays message "The server tried to redirect Opera to the alternative proxy "http://xxxxxxxx". For security reasons this is no longer supported."

So looks like the main browsers (haven't tried Safari) have de facto deprecated it.

Is it an optional code to handle? RFC2616 is extremely sparse in its description of the status code.

Origin
(source)
i77 Line folding RFC2616 - design - active
Description
Many implementations do not implement header line folding; should it be deprecated / removed?
Origin
(source)
i78 Relationship between 401, Authorization and WWW-Authenticate RFC2616 - design - active
Description
Are these mechanisms exclusive? I.e., can they only be used together, or can a cookie-based authentication scheme (for example) use 401?
Origin
(source)
i79 Content-* vs. PUT RFC2616 - design - active
Description

The description of PUT states:

"The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases."

That language sounds as if a server that ignores Content-Language (as opposed to storing it with the entity) MUST reject PUT requests that come with a Content-Language header. Is this really intended? Does anybody implement that?

Origin
(source)
i80 Content-Location isn't special RFC2616 - design - active
Description

The definition of Content-Location ends with:

"The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases."

This was added in RFC2616 (does not appear in RFC2068).

I have no problem allowing servers to ignore it. However:

  1. It seems that the meaning of Content-Location is universal for messages that carry an entity; I'm not sure what's the point in claiming that meaning does not apply to PUT or POST.
  2. Also: every time a limited set of methods is mentioned somewhere it feels like problematic spec writing. What makes PUT or POST so special in comparison to other methods? Maybe that they are the only methods in RFC2616 that carry request entity bodies? In which case the statement should be rephrased accordingly...
Origin
(source)
i81 Content Negotiation for media types RFC2616 - design - active
Description

HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out. The original theory of content negotiation was worked out when the idea of the web was that browsers would support a handful of media types (text, html, a couple of image types), and so it might be reasonable to send an 'accept:' header listing all of the types supported. But in practice as the web evolved, browsers would support hundreds of types of all varieties, and even automatically locate readers for content-types, so it wasn't practical to send an 'accept:' header for all of the types.

So content negotiation in practice doesn't use accept: headers except in limited circumstances; for the most part, the sites send some kind of 'active content' or content that autoselects for itself what else to download; e.g., a HTML page which contains Javascript code to detect the client's capabilities and figure out which other URLs to load. The most common kind of content negotiation uses the 'user agent' identification header, or some other 'x-...' extension headers to detect browser versions, among other things, to identify buggy implementations or proprietary extensions.

I think we should deprecate HTTP content negotiation, if only to make it clear to people reading the spec that it doesn't really work that way in practice.

Many people seem to use HTTP content negotiation as a motivation for adding 'version' parameters to MIME types or registering new MIME types, with the hopes that the MIME types or parameters would be useful in HTTP content negotiation, and we should warn them that it isn't really productive to do so. That's why it might be useful advice to add to the guidelines for registering MIME types, should those ever be updated.

This may also affect the text that describes the circumstances when a 406 may/must be sent.

Origin
(source)
i82 rel_path not used RFC2616 - editorial - active
Description

RFC2616 changed the ABNF for http_URL so that it doesn't use rel_path (as defined in RFC2396) anymore.

However, that definition is still "adopted" in section 3.2.1;

URIs in HTTP can be represented in absolute form or relative to some known base URI [11], depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with a scheme name followed by a colon. 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]). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and "authority" from that specification."

...and used in section 13.9.p.2:

"We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. See Section 9.1.1 for related information."

Origin
(source)
Proposal 1
  • get rid of the mention in 3.2.1, and
  • in 13.9 paragraph 2, replace "...query URLs (those containing a "?" in the rel_path part)..." with "...URLs containing a query part..."
i83 OPTIONS * and proxies RFC2616 - design - active
Description

The following text was in RFC2068, but dropped from RFC2616;

If a proxy receives a request without any path in the Request-URI and
the method specified is capable of supporting the asterisk form of
request, then the last proxy on the request chain MUST forward the
request with "*" as the final Request-URI. For example, the request

OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

would be forwarded by the proxy as

OPTIONS * HTTP/1.1
Host: www.ics.uci.edu:8001

after connecting to port 8001 of host "www.ics.uci.edu".

This makes it impossible for a proxy to forward an OPTIONS * request, because "*" is not a valid URI (as opposed to "/*").

One solution would be to reinstate the text, but that would require proxies to understand a method-specific case.

Origin
(source)
i84 Redundant cross-references RFC2616 - editorial - closed
Description

RFC 2616 sections 9.5 (POST) and 9.6 (PUT) have the following useless waste of bits.

POST requests MUST obey the message transmission requirements set out in section 8.2.

See section 15.1.3 for security considerations.

and

PUT requests MUST obey the message transmission requirements set out in section 8.2.

respectively. They can be safely deleted without changing HTTP.

Section 8.2 is not specific to PUT and POST. Likewise, a content-free forward pointer to just one of the many subsections on security consideration is a total waste of brain cells.

Those are just two examples of what can only be described as a spaghetti style of content-free cross-references within the spec that make it very hard to read. They should be removed in general at the editors' discretion.

Origin
(source)
Resolution (incorporated: 04)
As proposed.
i85 Custom Ranges RFC2616 - design - active
Description
Either flesh out how to define and use custom ranges, or remove them from the spec.
Origin
(source)
i86 Normative up-to-date references RFC2616 - editorial - closed
Description

the references below are normative and should be classified as such. None of them needs updating:

RFC1864 ("The Content-MD5 Header Field")

RFC2045 ("Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies")

RFC2046 ("Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types")

RFC2047 ("MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text")

RFC2119 ("Key words for use in RFCs to Indicate Requirement Levels")

RFC2617 ("HTTP Authentication: Basic and Digest Access Authentication")

Origin
(source)
Resolution (incorporated: 04)
As proposed.
i87 typo in 13.2.2 RFC2616 - editorial - closed
Description
s/ought to used/ought to be used/;
Origin
(source)
Resolution (incorporated: 04)
As proposed.
i88 205 Bodies RFC2616 - design - active
Description

Section 4.3 "Message Body" enumerates those messages that don't include a message-body;

All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length.

However, it does not list 205 (section 10.2.6).

Also if you look at the texts for 204, 304 and 205 responses, you see that 204 and 304 say "MUST NOT include a message-body", whereas 205 says "MUST NOT include an entity". 204 and 304 go on to say that the message is terminated at the first empty line, but 205 does not say that.

Proposal 1
Proposal 2
i89 If-* and entities RFC2616 - design - active
Description

The description of If(-None)-Match still refers to entity when it talks about ETag, should refer to entity tag, variant and requested variant.

Sections: 14.24 If-Match, 14.26 If-None-Match

Problematic text (same in both sections):

        
A client that has one or more entities previously
obtained from the resource can verify that one of those entities is
current by including a list of their associated entity tags in the

and later

        
or if "*" is given and any current entity exists for that resource

Problem:

ETag values is associated with variants, not entities. There is other uses of these conditionals than just simple entity caching which seems to be what the current text has in mind.

Origin
(source)
Proposal 1

From:

        
            A client that has one or more entities previously
            obtained from the resource can verify that one of those entities is
            current by including a list of their associated entity tags in the
            [...]
        

To:

            A client that has one or more entity tags previously obtained
            from the resource can verify that one of those variants matches
            the current requested variant by including a list of their
            associated entity tags in the [...]
        

From:

            or if "*" is given and any current entity exists for that resource
        

To:

                
            or if "*" is given and any current requested variant exists for
            that resource
        
i90 Delimiting messages with multipart/byteranges RFC2616 - design - active
Description

There appears to be some confusion as to when multipart/byteranges bodies have to be inspected to determine the message length. It seems that is widely considered optional and sometimes limited to ...

In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception is the "multipart/byteranges" type (appendix 19.2) when it appears in a 206 (Partial Content) response ...

... this particular case, even though the specification suggest the opposite, I read it to say, all implementations have to support that and support it in all messages, like requests and non-206 responses. Apache 2.2.6 for example treats

            
POST / HTTP/1.1
Host: example
Content-type: multipart/byteranges;
boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
...

as two requests, a zero-length POST and a --THIS_STRING_SEPARATES to the root which it does not support (which seems to be a bug in itself).

Would it be possible, for example, to discourage implementations to ever generate messages where the message length is determined by this type, and limit having to read it to 206 responses, as the text above suggests?

Origin
(source)
Proposal 1

The correct resolution is to fix 4.4 Message Length to restrict rule 4 to 206 responses only.

I would like to also deprecate this message delimiting method as obsolete. chunked encoding fills the gap nicely.

i91 Duplicate Host header requirements RFC2616 - editorial - active
Description

Section 9:

                
The set of common methods for HTTP/1.1 is defined below. Although
this set can be expanded, additional methods cannot be assumed to
share the same semantics for separately extended clients and servers.
                          
The Host request-header field (section 14.23) MUST accompany all
HTTP/1.1 requests.

...any reason why the Host header requirement is listed here so prominently (duplicating text from 14.23)?

Origin
(source)
i92 Empty Host Headers - BNF RFC2616 - editorial - active
Description

The specification states "If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value" but the grammar does not seem to allow this.

            
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

should be changed into

Host = "Host" ":" [ host [ ":" port ] ] ; Section 3.2.2
Origin
(source)
i93 Repeating single-value headers RFC2616 - design - active
Description

Section 4.2:

            
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].

Now this seems to be kind of backwards, wouldn't it be *much* clearer if it said:

            
Multiple message-header fields with the same field-name MUST NOT be
present in a message unless the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].

That being said, do we have a recommendation for recipients when that requirement is violated? I would assume that servers SHOULD return a 400 (Bad Request), but what about clients?

Origin
(source)
i94 Reason-Phrase BNF RFC2616 - design - active
Description

Looking at...:

            
TEXT           = <any OCTET except CTLs, but including LWS>
LWS            = [CRLF] 1*( SP | HT )
CRLF           = CR LF

Reason-Phrase  = *<TEXT, excluding CR, LF>

So was the real intent to say: any OCTET except CTLs?

Origin
(source)