Subject: WGLC p1: Delimiting messages with multipart/byteranges

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 29 Apr 2013 19:47:35 +0100

Hi,

The p1 HTTPbis draft has removed using multipart/byteranges as a message delimiter in 206 responses (which was previously allowed by RFC2616).

I see this was originally tracked as Ticket #90 and the outcome was to deprecate such behaviour in all cases including in 206 responses with Content-Type: multipart/byteranges (which is the only case I care about).

This decision makes previously conforming implementations (such as our reverse proxy implementation) now non-conformant and the alternatives of: (A) close connection after every multipart/byteranges response or (B) pre-calculate message body length (including header/boundary bytes for each byterange) in advance, are inconvenient.

Would it be possible to re-allow use of multipart/byteranges as a message delimiter in the case where it is a 206 response AND there is no Transfer-Encoding AND there is no Content-Length so that implementations such as ours are classed as conformant again?

Even if it is decided to stick with the current state of affairs in -22 where generating 206 responses that use multipart/byteranges as a delimiter is forbidden, the specification should still specify how to parse such responses in a backwardly compatible manner as generating such responses was previously allowed & used and so User Agents should still expect to receive them from pre-httpbis implementations.

Thanks
Ben

---

From: Zhong Yu <[email-masked]>
Date: Mon, 29 Apr 2013 16:39:01 -0500

On Mon, Apr 29, 2013 at 1:47 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> Hi,
>
> The p1 HTTPbis draft has removed using multipart/byteranges as a message
> delimiter in 206 responses (which was previously allowed by RFC2616).
>
> I see this was originally tracked as Ticket #90 and the outcome was to
> deprecate such behaviour in all cases including in 206 responses with
> Content-Type: multipart/byteranges (which is the only case I care about).
>
> This decision makes previously conforming implementations (such as our
> reverse proxy implementation) now non-conformant and the alternatives of:
> (A) close connection after every multipart/byteranges response or (B)
> pre-calculate message body length (including header/boundary bytes for each
> byterange) in advance, are inconvenient.
>

What about (C) apply chunked coding on response body?  It might be easier
than calculating Content-Length.

Zhong Yu

> Would it be possible to re-allow use of multipart/byteranges as a message
> delimiter in the case where it is a 206 response AND there is no
> Transfer-Encoding AND there is no Content-Length so that implementations
> such as ours are classed as conformant again?
>
>
> Even if it is decided to stick with the current state of affairs in -22
> where generating 206 responses that use multipart/byteranges as a delimiter
> is forbidden, the specification should still specify how to parse such
> responses in a backwardly compatible manner as generating such responses
> was previously allowed & used and so User Agents should still expect to
> receive them from pre-httpbis implementations.
>
> Thanks
> Ben
>
>
>

---

From: Zhong Yu <[email-masked]>
Date: Mon, 29 Apr 2013 17:45:14 -0500

Question about trailing CRLF of a multipart body. RFC2046 defines

     multipart-body := [preamble CRLF]
                       dash-boundary transport-padding CRLF
                       body-part *encapsulation
                       close-delimiter transport-padding
                       [CRLF epilogue]

RFC2616 forbids "epilogue" in http messages, but what about the trailing
CRLF? I know browsers do include a trailing CRLF when submitting
multipart/form-data requests. Is that also the common practice for
multipart responses from servers?

Zhong Yu

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Apr 2013 12:43:20 +1000

On 30/04/2013, at 7:39 AM, Zhong Yu <[email-masked]> wrote:
> 
> What about (C) apply chunked coding on response body?  It might be easier than calculating Content-Length.

+1; this is where the discussion led us. Delimitation by multipart/byteranges was considered not interoperable, because it was not widely implemented.

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