Subject: #90: multipart/byteranges

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Nov 2008 17:10:45 -0800

So far, discussion of this issue <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/90 
 > seems to centre around disallowing the use of multipart/byteranges  
as a message delimiter, because it is not widely implemented, and  
because chunked encoding can be used instead.

Any objections to doing so?

--
Mark Nottingham     http://www.mnot.net/

---

From: "Robert Brewer" <[email-masked]>
Date: Fri, 14 Nov 2008 09:09:56 -0800

Mark Nottingham wrote:
> So far, discussion of this issue
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/90>

and Brian Behlendorf answered via his time machine [1]
> The main purpose of this algorithm is graceful recovery from
> aborted transfers.

Robert Brewer
[email-masked]

[1]
http://www.hpl.hp.com/personal/ange/archives/archives-95/http-wg-archive
/1868.html

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Nov 2008 10:08:40 -0800

That seems to describe the general partial content mechanism (i.e.,  
using byteranges negotiation in HTTP), not the specific motiviation  
for using multipart/byteranges as a message delimiter.

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 14 Nov 2008 22:49:17 +0100

> Any objections to doing so?

None here, except that I don't really see it needed.

P1 4.4 Message Length (and 2616 4.4) already supports this view
indirectly, with multipart/byteranges being the next lowest priority
message delimiting, only close of connection has lower priority..

P1 4.4 #4 also considerably restricts when this media type is allowed
with a clear MUST NOT.

The text in the multipart/byteranges appendix is only relevant in the
scope where this media type is allowed to be used. P5 Appendix A.
Internet Media Type multipart/byteranges is also quite clear on that
this media type only applies to 206 responses under specific
conditions. 

So I can't find anything even remotely indicating multipart/byteranges
is meant to be generally accepted or parsed outside the context of 206
responses to multi-range request. 

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Nov 2008 18:49:07 -0800

I think the issue is that allowing a special case where it is allowed  
makes parsers significantly more complex, and isn't in wide use anyway.

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 15 Nov 2008 17:19:34 +0100

> makes parsers significantly more complex, and isn't in wide use anyway.

Now I am confused what this is about.

multipart/byteranges as delimiter is defenitely in wide use for 206
responses.

What is not supported in wide use is multipart/byteranges as delimiter
for any other purpose such as sending requests..

I don't see how we can disallow multipart/byteranges as delimiter. All
clients sending multi-range requests MUST support it in 206 responses to
such requests. A client not supporting multipart/byteranges as delimiter
MUST NOT sent a multi-ranged request without also using Connection:
close.

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 17 Nov 2008 02:43:20 +0000

> MUST NOT sent a multi-ranged request without also using Connection:

And this includes intermediaries blindly forwarding multi-range
requests.

The way to disallow multipart/byteranges as delimiter, then, so that
clients/intermediaries don't have to parse it, while remaining
compatible with the existing web, is to also disallow generation or
forwarding of multi-range requests in the current format.  IF
multi-range requests are still wanted, a different form of multi-range
requests would be needed which does not permit this type of delimiting
in the response.

-- Jamie