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

RE: must a partial response range be exact?

From: Brian Smith <brian@briansmith.org>
Date: Sun, 12 Oct 2008 11:04:05 -0500
To: "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Henrik Nordstrom'" <henrik@henriknordstrom.net>, "'A. Rothman'" <amichai2@amichais.bounceme.net>, <ietf-http-wg@w3.org>
Message-ID: <EF83BA18B6854FABA5E6B656839E5DE5@T60>

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

* The server is free to reject any request (overlapping range requests or
otherwise) where the request would exhaust too many server resources.

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

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