Forwarded message 1
The specification for Range now says:
14.36.2 Range Retrieval Requests
HTTP retrieval requests using conditional or unconditional
GET methods may request one or more sub-ranges of the
entity, instead of the entire entity, using the Range
request header, which applies to the entity returned as the
result of the request:
However, I believe that the spec is silent on what the server
should return for a Range if it also uses a content-coding, such
as "gzip".
More concretely:
Suppose the client sends:
GET /foo.html HTTP/1.1
Host: bar.com
Range: bytes=100-199
Accept-Encoding: gzip
and the server returns
HTTP/1.1 206 OK
Content-Range: bytes 100-199/400
Content-Type: text/html
Content-coding: gzip
Then should then 100 bytes covered by the Range/Content-Range
refer to the second hundred bytes of the HTML file before
compression, or to the second hundred bytes of the compressed
form?
It seems to me that the only reasonable interpretation is that
Range/Content-Range should apply to the unencoded form of the
response, since the client's ultimate goal is to obtain a specific
piece of the unencoded form; the use of compression is only
a temporary phase that the response goes through while it is
being transmitted.
However, by a strict reading of the phrase "which applies to the entity
returned as the result of the request", combined with the HTTP/1.1
definition of "entity":
The information transferred as the payload of a request
or response. An entity consists of metainformation in the
form of entity-header fields and content in the form of
an entity-body, as described in section 7.
one would have to use the other interpretation: that the Range
applies to the compressed form, since this is the "payload of the
[response]".
One way to resolve this issue would be to go back about 18 months
and undo the decision made about adopting the MIME definition
of "entity." I argued then that this was a mistake; I continue
to believe that this is not only a mistake, but one that was made
without any lack of warning. But I don't expect to win this battle.
Another approach would be to define a new term, such as "instance",
to mean what "entity" should have meant (by the standard English
definition of the word "entity"). But I doubt you would accept
this change at this stage in the process.
So, with some trepidation that this is not the only potential
error lurking in the the spec as the result of the "entity" term,
I suggest changing the first paragraph of 14.36.2 to read:
HTTP retrieval requests using conditional or unconditional
GET methods may request one or more sub-ranges of the
entity, instead of the entire entity, using the Range
request header, which applies to the entity returned as the
result of the request, prior to the application of
any content-coding:
-Jeff