Re: must a partial response range be exact?

If this is agreed upon, the spec has to be changed at least to some 
degree, since its current wording conflicts with these guidelines both 
explicitly and implicitly in various places. Also note that these 
guidelines do break existing implementations, since the RFC wording all 
but encourages server-side range recombinations. Some possible fixes:

"When an HTTP message includes the content of a single range (for
  example, a response to a request for a single range, or to a request
  for a set of ranges that overlap without any holes)"

=> the sentence in parentheses should be only "(a response to a request 
for a single range)", or dropped altogether

"When an HTTP message includes the content of multiple ranges (for
   example, a response to a request for multiple non-overlapping
   ranges), these are transmitted as a multipart message."

=> 'for example' and 'non-overlapping', or the entire sentence in 
parentheses, should be dropped

"A response to a request for a single range MUST NOT be sent using the
   multipart/byteranges media type."

=> maybe add explicitly that "Clients should accept single-part 
multipart/byterange responses"

"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."

=> entire sentence must be dropped (resolving issue 133 in accordance to 
these guidelines - I like this solution better than the other proposed 
one since it reduces the complixity and ambiguity of the spec)

"When a client requests multiple byte-ranges in one request, the
   server SHOULD return them in the order that they appeared in the
   request"

=> maybe add that the ranges should be returned exactly as requested 
(full correspondence of both number and order of ranges), and further 
state explicitly that clients should accept anything the server throws 
at them

Finally, possibly add a paragraph with what the client should/shouldn't 
send (trivially combinable ranges, meaningful order, obviously 
overlapping ranges), though with this new set of guidelines the rules 
are simpler and less ambiguous, so this paragraph might be redundant and 
common sense will suffice. Maybe still warn that if the client does 
something too wasteful, the server can reject it, and if so, with what 
error code (and/or full 200 response).


Regards,

Amichai

Julian Reschke wrote:
> 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
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.173 / Virus Database: 270.8.0/1720 - Release Date: 11/10/2008 15:59
>
>