W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

new editorial issue RANGE_WITH_CONTENTCODING

From: Jim Gettys <jg@pa.dec.com>
Date: Fri, 14 Nov 1997 12:43:11 -0800
Message-Id: <9711142043.AA22526@pachyderm.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com



attached mail follows:


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
Received on Friday, 14 November 1997 12:47:33 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:02 EDT