Re: Issue 133, was: multipart/byteranges minimum number of parts

Obviously 2 is the correct answer.


responding with multipart/byteranges is only OK if the client issued a
request with multiple ranges, as this is how the client indicates it
supports multipart/byteranges.

It's entirely fine to respond with a single range within that
multipart/byteranges response if the ranges adds up to a single range or
if the server otherwise chooses to respond with a single range.

The MUST NOT is to respond with multipart/byteranges if the request was
for only one range as there is no way to know if the client supports
multipart/byteranges in response to such requests.

As soon as the request is multi-ranged the server is free to choose
multipart/byteranges if it likes as it then knows the client supports
this, even if not strictly needed for the specific response.

Responding with multipart/byteranges when there is only a single range
in the response is sub-optimal, but does not make it an invalid response
to a multi-range request.

Regards
Henrik






On mån, 2008-10-06 at 16:17 +0200, Julian Reschke wrote:
> Ok,
> 
> so the choices seem to be:
> 
> (1) in 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-04.html#rfc.section.6.2>, 
>   change
> 
> "A response to a request for a single range MUST NOT be sent using the 
> multipart/byteranges media type. 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. ...
> 
> to
> 
> "A response to a request for a single range MUST NOT be sent using the 
> multipart/byteranges media type. Furthermore, a response to a request 
> for multiple ranges, whose result is a single range, MUST NOT be sent 
> using the multipart/byteranges media type. ..."
> 
> or
> 
> (2) in 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-04.html#rfc.section.A>, 
> change
> 
> "The multipart/byteranges media type includes two or more parts, each 
> with its own Content-Type and Content-Range fields."
> 
> to
> 
> "The multipart/byteranges media type includes one or more parts, each 
> with its own Content-Type and Content-Range fields."
> 
> 
> Note that RFC 2046 says 
> (<http://tools.ietf.org/html/rfc2046#section-5.1.1>):
> 
> "The use of the "multipart" media type with only a single body part may 
> be useful in certain contexts, and is explicitly permitted."
> 
> 
> Observation: this is an edge case a client can easily avoid, by not 
> construction a request with overlapping ranges. Therefore my 
> recommendation would be to make the minimal change that fixes, the 
> inconsistency, which IMHO is the second option.
> 
> BR, Julian
> 
> 
> 
> Julian Reschke wrote:
> > 
> > A. Rothman wrote:
> >> Hi!
> >>
> >> The spec contradicts itself regarding the minimum number of parts in a 
> >> multipart/byteranges response: On the one hand, "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", while on the 
> >> other hand, "The multipart/byteranges media type includes two or more 
> >> parts". If a multipart/byteranges media type indeed must include two 
> >> or more parts, the first statement makes for an illegal response. And 
> >> if a one-part response is valid, then the second statement is incorrect.
> >>
> >> Since the spec also mandates that a client requesting a single range 
> >> must never receive a multipart/byteranges response, it seems like the 
> >> intention was to make it possible for a client to support partial 
> >> retrieval without having to implement multipart support at all, in 
> >> which case it would have been more straightforward if the spec simply 
> >> required all single-range responses to use Content-Range and not 
> >> multipart/byteranges. For backwards compatibility,  it can 
> >> encourage/require multipart/byteranges recipients to properly handle 
> >> single-part messages as well, which is very likely the case in 
> >> existing implementations.
> >>
> >> In any case, this contradiction should be fixed and the use cases 
> >> clarified.
> >> ...
> > 
> > Hi Amichai,
> > 
> > I believe your analysis is correct, and I have opened issue 
> > <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/133> accordingly.
> > 
> > BR, Julian
> > 
> > 
>