Re: content-encoding and range headers

Stefan,

	The following paper, written by one of the RFC 2616 authors,
may help you to navigate through the ranges, transfer, and content
encoding mess (see Figure 4-1b on page 8 if you do not want to read
the entire paper).

	"Clarifying the Fundamentals of HTTP"
	Jeffrey C. Mogul
	WWW Conference, 2002
	http://research.compaq.com/wrl/people/mogul/www2002/mogulwww2002preprint.pdf

HTH,

Alex.

On Tue, 10 Dec 2002, Stefan Eissing wrote:

> I have unsuccessfully tried to google an answer to this, maybe someone
> on this list has an answer.
>
> My understanding of 2616 is that range is applied to the
> content-encoded entity. So if an entity is gzipped, the
> byte selection is applied on the gzipped representation.
> Given that:
>
> What is a server to do when a client sends a request with
> Accept-Encoding: gzip
> Range: bytes=0-499
>
> Is the server free to chose the content-encoding to its liking
> (identity or gzip)?
>
> Assuming there is a second request later
> Accept-Encoding: gzip
> Range: bytes=500-1000
>
> Is the server allowed to use another content-encoding in the response?
>
> If yes, that would mean it is purely the client's responsibility
> to detect varying content-encodings in partial responses and
> act accordingly?
>
> Or did I misunderstand the order of range and content-encoding
> and the byte range is selected on the unencoded entity and
> content-encoding is applied *after* the range selection process?
>
> In that case, a server storing gzipped entities has some work to do
> answering range request. It would then need to "uncompress"
> (ungzip?) the entity before it can select the correct range.
>
>   Thanks for any help.
>
> //Stefan
>
>
>

-- 
                            | 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 10:59:42 UTC