W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: multipart 206 responses in HTTP/2.0

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 4 Oct 2013 23:52:25 -0700
Message-ID: <CAP+FsNeOaYYfqOagv-fMb-n39k9ke66VLT5r7XBbj9TSAOU7eg@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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.
>>
>>
>
>
Received on Saturday, 5 October 2013 06:52:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC