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: Sun, 12 Oct 2008 19:59:32 +0200
Message-ID: <48F23B04.8090403@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: 'Henrik Nordstrom' <henrik@henriknordstrom.net>, "'A. Rothman'" <amichai2@amichais.bounceme.net>, ietf-http-wg@w3.org

Brian Smith wrote:
>> Brian, do you disagree with the proposed resolution for issue 133, or 
>> did you miss it?
> * Clients should accept single-part multipart/byterange responses, but
> servers shouldn't generate them since RFC 2616 says that every
> multipart/byterange request has at least two parts.
> * Clients should not send range requests that can be trivially combined
> (e.g. 0-2, 3-5), but they should accept any combination that the server
> does. Server implementers shouldn't waste time trying to combine ranges; if
> a client split contiguous ranges into separate ranges, it probably had a
> reason for doing so.
> * Clients should send ranges in the order they want the ranges to be
> returned; servers shouldn't reorder out-of-order ranges (3-5, 0-2), even if
> they are contiguous. Reordering and combining these ranges defeats the
> purpose of splitting the request into ranges in the first place (e.g. Adobe
> Reader's behavior).
> * Clients shouldn't send obviously overlapping ranges (ranges that overlap
> for any reason other than the combination of a regular range and a suffix
> range).
> * The server is free to reject any request (overlapping range requests or
> otherwise) where the request would exhaust too many server resources.

I think I agree with all these statements.

What I still want to know is: do we need to make any additional changes 
to the spec? Is this all just "common sense", or should something of 
this become a normative requirement? If not, should it be added as guidance?

BR, Julian
Received on Sunday, 12 October 2008 18:00:26 UTC

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