Re: must a partial response range be exact?

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