Subject: multipart 206 responses in HTTP/2.0

From: Osama Mazahir <[email-masked]>
Date: Fri, 4 Oct 2013 22:46:42 +0000

Have we thought about how we are supposed to send a 206 multipart response in HTTP/2.0?

Section 8.1 of draft-ietf-httpbis-http2-06 states:

   Other frames MAY be interspersed with these frames, but those frames
   do not carry HTTP semantics.  In particular, HEADERS frames (and any
   CONTINUATION frames that follow) other than the first and optional
   last frames in this sequence do not carry HTTP semantics.

   Trailing header fields are carried in a header block that also
   terminates the stream.  That is, a sequence starting with a HEADERS
   frame, followed by zero or more CONTINUATION frames, that carries an
   END_STREAM flag on the last frame.  Header blocks after the first
   that do not terminate the stream are not part of an HTTP request or
   response.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Oct 2013 16:00:11 -0700

> Have we thought about how we are supposed to send a 206 multipart response

Multipart MIME is invisible to HTTP, as it always has been.  The
entire MIME multipart body will just be payload bytes.  Thus, the MIME
headers that are included for each multipart portion will be sent in
DATA frames.

A 206 status code isn't special in this regard, I'm not sure what you
are getting at there.

---

From: James M Snell <[email-masked]>
Date: Fri, 4 Oct 2013 16:11:29 -0700

I have a draft proposal for this I'm holding on to that uses extension
frames to replace multipart mime. I am holding off publishing it until the
basic lower level protocol work is completed.
On Oct 4, 2013 3:50 PM, "Osama Mazahir" <[email-masked]> wrote:

>  Have we thought about how we are supposed to send a 206 multipart
> response in HTTP/2.0?****
>
> ** **
>
> Section 8.1 of draft-ietf-httpbis-http2-06 states:****
>
> ** **
>
>    Other frames MAY be interspersed with these frames, but those frames***
> *
>
>    do not carry HTTP semantics.  In particular, HEADERS frames (and any***
> *
>
>    CONTINUATION frames that follow) other than the first and optional****
>
>    last frames in this sequence do not carry HTTP semantics.****
>
> ** **
>
>    Trailing header fields are carried in a header block that also****
>
>    terminates the stream.  That is, a sequence starting with a HEADERS****
>
>    frame, followed by zero or more CONTINUATION frames, that carries an***
> *
>
>    END_STREAM flag on the last frame.  Header blocks after the first****
>
>    that do not terminate the stream are not part of an HTTP request or****
>
>    response.****
>
> ** **
>
> ** **
>
> ** **
>

---

From: Osama Mazahir <[email-masked]>
Date: Fri, 4 Oct 2013 23:24:41 +0000

So the current thinking is that the separators, the per-body headers, etc would just get stuffed into DATA frames? 

Section 4.1 in draft-ietf-httpbis-p5-range-24 has the following example:
     HTTP/1.1 206 Partial Content
     Date: Wed, 15 Nov 1995 06:25:24 GMT
     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
     Content-Length: 1741
     Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

     --THIS_STRING_SEPARATES
     Content-Type: application/pdf
     Content-Range: bytes 500-999/8000

     ...the first range...
     --THIS_STRING_SEPARATES
     Content-Type: application/pdf
     Content-Range: bytes 7000-7999/8000

     ...the second range
     --THIS_STRING_SEPARATES--

So the above example would translate into a HEADERS frame (+END_HEADERS) covering the first set of headers (e.g. date, last-modified, content-length, content-type) and then everything thereafter (separators, "Content-Type: application/pdf", content-range, binary data, etc) would be wrapped into a DATA frame?

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Friday, October 4, 2013 4:00 PM
To: Osama Mazahir
Cc: HTTP Working Group
Subject: Re: multipart 206 responses in HTTP/2.0

On 4 October 2013 15:46, Osama Mazahir <[email-masked]> wrote:
> response in HTTP/2.0?

Multipart MIME is invisible to HTTP, as it always has been.  The entire MIME multipart body will just be payload bytes.  Thus, the MIME headers that are included for each multipart portion will be sent in DATA frames.

A 206 status code isn't special in this regard, I'm not sure what you are getting at there.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Oct 2013 17:07:10 -0700

> Section 4.1 in draft-ietf-httpbis-p5-range-24 has the following example:

HEADERS
>      Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
END_HEADERS

DATA
>      --THIS_STRING_SEPARATES--
END_STREAM

> So the above example would translate into a HEADERS frame (+END_HEADERS) covering the first set of headers (e.g. date, last-modified, content-length, content-type) and then everything thereafter (s…

Yep.  The content-type is multipart/byteranges;... .  The content
starts at the first '--' + boundary and ends at the last '--' +
boundary + '--', all of which gets carried in DATA frames.

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 05 Oct 2013 16:26:20 +1300

On 5/10/2013 12:11 p.m., James M Snell wrote:
> frames to replace multipart mime. I am holding off publishing it until 
> the basic lower level protocol work is completed.
>

Since requests and responses are cheap now. How about just indicating 
that clients send multiple requests, one for each range?
That way no range is blocked awaiting delivery of an earlier range and 
the multipart encoding complexity is dropped completely.

Amos

> On Oct 4, 2013 3:50 PM, "Osama Mazahir" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 4 Oct 2013 23:52:25 -0700

This works assuming no http/1 gateway somewhere.
Mime/multipart  has always been particularly annoying, though.

-=R

On Fri, Oct 4, 2013 at 8:26 PM, Amos Jeffries <[email-masked]> wrote:

> Since requests and responses are cheap now. How about just indicating that
> clients send multiple requests, one for each range?
> That way no range is blocked awaiting delivery of an earlier range and the
> multipart encoding complexity is dropped completely.
>
> Amos
>
>
>
>  On Oct 4, 2013 3:50 PM, "Osama Mazahir" <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 05 Oct 2013 10:19:02 +0200

> Mime/multipart  has always been particularly annoying, though.

I'd prefer to replace multipart by an easier-to-process binary format 
that could be used in HTTP/1.1 as well.

Best regards, Julian

---

From: Roberto Peon <[email-masked]>
Date: Sat, 5 Oct 2013 01:37:57 -0700

I think that is what James was proposing as well.
I'd love to see that-- it shouldn't be rocket science, and it may as well
be done if we're ever going to do it.
-=R

On Sat, Oct 5, 2013 at 1:19 AM, Julian Reschke <[email-masked]>wrote:

> I'd prefer to replace multipart by an easier-to-process binary format that
> could be used in HTTP/1.1 as well.
>
> Best regards, Julian
>
>

---

From: Roberto Peon <[email-masked]>
Date: Sat, 5 Oct 2013 01:38:42 -0700

Oh yea, nearly forgot.
I believe the 'end of message' bit, currently reserved in the data frame
would work well for this.
-=R

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 5 Oct 2013 17:32:24 +0100

> So the above example would translate into a HEADERS frame (+END_HEADERS) covering the first set of headers (e.g. date, last-modified, content-length, content-type) and then everything thereafter (s…

Correct.