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

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Oct 2008 17:44:03 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Oct 2008 16:17:06 +0200

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:
>> 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.
>>
>> 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 
>> single-part messages as well, which is very likely the case in 
>> existing implementations.
>>

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 08 Oct 2008 23:29:38 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Oct 2008 17:03:44 +0200

> to a multi-range request.

Ok, proposed change in 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/133/133.diff>...

BR, Julian