W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: must a partial response range be exact?

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 01 Oct 2008 17:58:53 +0200
Message-ID: <48E39E3D.9010204@gmx.de>
To: "A. Rothman" <amichai2@amichais.net>
CC: ietf-http-wg@w3.org

A. Rothman wrote:
> If a client requests partial range(s) using the Range header, is it 
> legal for the server to return a partial result which is larger than the 
> requested range(s) but fully contains it? This would allow a server to 
> satisfy a request for multiple ranges by returning a Content-Range 
> response with a single range that contains all of the requested data, 
> thus allowing a light-weight server to be able to support partial 
> content retrieval without having to implement the added complexity of 
> multipart/byteranges handling and range-skipping.

I would say it's always legal, as the response is self-descriptive.

> It is not apparent from the spec whether this is allowed or not - 
> perhaps it should be stated explicitly to avoid confusion (by both the 
> sender and recipient of the response).
> If it is not allowed, the alternative for such a server would be to 
> support single-range requests using Content-Range partial responses, and 
> ignore any multiple-range requests by always responding to them with 
> full content (200) - this is implied to be legal according to the spec 
> since range support is optional in the first place - but would be much 
> less efficient.
> So - must a partial response range be exact or not?

Do you have a specific use case in mind? The only real-world scenario I 
have seen where multiple parts were requested was with Adobe Acrobat 
(which, as far as I recall, asks for content from the beginning and from 
the end (the toc?))? That case doesn't seem to benefit a lot from the 
proposal you made...

Are there other clients you're thinking of, or is this a purely 
theoretical question?

BR, Julian
Received on Wednesday, 1 October 2008 15:59:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC