multipart 206 responses in HTTP/2.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

multipart 206 responses in HTTP/2.0

Osama Mazahir

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.

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

Martin Thomson-3
On 4 October 2013 15:46, Osama Mazahir <[hidden email]> wrote:
> Have we thought about how we are supposed to send a 206 multipart 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.

Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

James M Snell
In reply to this post by Osama Mazahir

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" <[hidden email]> 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.

 

 

 

Reply | Threaded
Open this post in threaded view
|

RE: multipart 206 responses in HTTP/2.0

Osama Mazahir
In reply to this post by Martin Thomson-3
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:[hidden email]]
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 <[hidden email]> wrote:
> Have we thought about how we are supposed to send a 206 multipart
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

Martin Thomson-3
On 4 October 2013 16:24, Osama Mazahir <[hidden email]> wrote:
> Section 4.1 in draft-ietf-httpbis-p5-range-24 has the following example:

HEADERS
>      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
END_HEADERS

DATA

>      --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--
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 (separators, "Content-Type: application/pdf", content-range, binary data, etc) would be wrapped into a DATA frame?

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.

Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

Amos Jeffries-2
In reply to this post by James M Snell
On 5/10/2013 12:11 p.m., James M Snell wrote:
>
> 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.
>

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" <[hidden email]
> <mailto:[hidden email]>> 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

Roberto Peon-2
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 <[hidden email]> wrote:
On 5/10/2013 12:11 p.m., James M Snell wrote:

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.


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" <[hidden email] <mailto:[hidden email]>> 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.




Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

Julian Reschke
On 2013-10-05 08:52, Roberto Peon wrote:
> This works assuming no http/1 gateway somewhere.
> Mime/multipart  has always been particularly annoying, though.
>
> -=R

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


Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

Roberto Peon-2
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 <[hidden email]> wrote:
On 2013-10-05 08:52, Roberto Peon wrote:
This works assuming no http/1 gateway somewhere.
Mime/multipart  has always been particularly annoying, though.

-=R

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


Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

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


On Sat, Oct 5, 2013 at 1:37 AM, Roberto Peon <[hidden email]> wrote:
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 <[hidden email]> wrote:
On 2013-10-05 08:52, Roberto Peon wrote:
This works assuming no http/1 gateway somewhere.
Mime/multipart  has always been particularly annoying, though.

-=R

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



Reply | Threaded
Open this post in threaded view
|

Re: multipart 206 responses in HTTP/2.0

Alexey Melnikov
In reply to this post by Osama Mazahir
On 5 Oct 2013, at 00:24, Osama Mazahir <[hidden email]> wrote:

> 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?

Correct.

> -----Original Message-----
> From: Martin Thomson [mailto:[hidden email]]
> 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 <[hidden email]> wrote:
>> Have we thought about how we are supposed to send a 206 multipart
>> 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.