Re: multipart 206 responses in HTTP/2.0

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 <squid3@treenet.co.nz> 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" <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.
>>
>>
>
>