RFC2616bis Issues

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"?

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

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

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.

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

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.

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.

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

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.

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.

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)

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.

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

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

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?

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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?

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

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.

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

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.

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.

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.

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?

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

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

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?

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?