Re: multipart 206 responses in HTTP/2.0

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" <OSAMAM@microsoft.com 
> <mailto:OSAMAM@microsoft.com>> 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.
>

Received on Saturday, 5 October 2013 03:26:53 UTC