Re: content-encoding and range headers

On 10 Dec 2002, Scott Lawrence wrote:

> But Accept-Encoding does not _require_ the server to use the specified
> encoding, it _offers_ to accept it.  So the request:
>
>  GET /foo HTTP/1.1
>  Host: example.com
>  Accept-Encoding: gzip
>  Range: 10000-19999
>
> might return two completely different parts of /foo depending on
> whether or not the server chose to apply the Content-Encoding.  Since
> HTTP is stateless, you can't even count on any given server making the
> same choice each time.
>
> If you believe that interpretation, then I think you must conclude
> that the combination is not very useful to the client.

I think you are right it general, though the above combination might
still be useful in some variations. For example,

  GET /foo HTTP/1.1
  Host: example.com
  Accept-Encoding: gzip
  Range: 0-5000

may be useful for a client that just needs to peek at the first 5000
bytes of an unencoded content (at most) and can uncompress the entity
if needed. The above will save bandwidth for content that compresses
to fewer than 5000 bytes. Again, this is clearly a rather exotic (but
HTTP-compliant?) usage.

Note that if the client really needs 10000-19999 unencoded content
bytes, the request below could be used instead:

  GET /foo HTTP/1.1
  Host: example.com
  TE: gzip
  Range: 10000-19999

Since transfer-coding is applied after the range is selected, the
client is guaranteed to receive the same content bytes, and the server
has an opportunity to compress the response to save bandwidth.
Transfer-coding will probably (but not necessarily) cost extra CPU
cycles.

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Tuesday, 10 December 2002 11:59:41 UTC