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