RE: must a partial response range be exact?

Julian Reschke wrote:
> Brian Smith wrote:
> > Henrik Nordstrom wrote:
> >> A linear sequence of in-order ranges MAY be merged in the 
> >> response. If there is only a single range left after such 
> >> merges then it SHOULD be sent as a Content-Range response 
> >> instead of multipart/byteranges, but MAY be sent as 
> >> multipart/byteranges is the sender prefer..The recipient MUST 
> >> accept both as valid responses, in addition to the 1-1 mapped 
> >> multipart/byteranges response or any other response that do 
> >> cover the requested ranges including (but not limited to) a 
> >> full non-ranged response.
> > 
> > This is how I read it too, except for the "but MAY be sent as
> > multipart/byteranges." multipart/byteranges requires two parts.
> 
> 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.

Regards,
Brian

Received on Sunday, 12 October 2008 16:04:46 UTC