Re: must a partial response range be exact?

ok, this is much clearer wording than the spec and the added 'recipient 
MUST' paragraph makes it explicit that clients MUST properly handle any 
form of (appropriate) response which includes the requested data, which 
from the existing spec is unclear - the reason I raised this question in 
the first place... any chance we'll see such improved wording in the new 
spec?


Also, where does the 'ordering' SHOULD clause at hand fit here? "When a 
client requests multiple out-of-order byte-ranges in one request , the 
server SHOULD return them as multipart/byteranges in the order that they 
appeared in the request" ?


btw do u think it is worth the added complexity to the spec and server 
implementation? is there some sort of usage/support statistics on 
clients that make use of out-of-order mutliple-ranges requests which 
show it to be worthwhile?


Regards,


Amichai


Henrik Nordstrom wrote:

> On tor, 2008-10-09 at 19:59 +0000, A. Rothman wrote:
>
>   
>> However, if that is so, then given that "A response to a request for
>> multiple ranges, whose result is a single range, MAY be sent as a
>> multipart/byteranges media type with one part", the spec MAY have this
>> SHOULD clause bite itself as well (in exactly the same sense as
>> returning a single Content-Range response)...
>>     
>
> My reading:
>
> 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.
>
> Regards
> Henrik
>