W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: END_SEGMENT and headers, #2

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 18 Apr 2014 14:29:26 -0700
Message-ID: <CAP+FsNfjx=LV1tBcKGHMWY8bBfpnk+8GpvtyBt2T7mB9NB3vqw@mail.gmail.com>
To: Erik Nygren <erik@nygren.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, David Krauss <potswa@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
I think that, other than the overhead, HEADERS DATA(0 payload +
END_SEGMENT) is the same as HEADERS(ENDSEGMENT).

For messaging protocols which solely used HEADERS frames, the overhead
would be unfortunate.
-=R


On Fri, Apr 18, 2014 at 2:21 PM, Erik Nygren <erik@nygren.org> wrote:

> I guess the specific case for wanting END_SEGMENT in HEADERS is when the
> HEADERS relate directly to the preceeding segment DATA,
>
> An example use-case is for chunked encoding extensions.  In HTTP/2 it
> seems like these might be best handled as HEADERS (perhaps with a special
> name prefix or flag?) in-between segments.  Some additional places I'm
> aware of where this may come up:
>
> * I know of one system that uses HTTP/1.1 chunked extensions hop-by-hop
> for end-to-end data integrity for anti-data-corruption (ie, by having a
> fingerprint computed on the fly for each segment).
> * ICAP uses a chunk extension of "ieof" as part of its signalling
> * It looks like websockets may also have some similar use-cases for
> wanting inter-segment signalling.
> * Another case this might be relevant for would be the CONNECT method
> where it may be desirable to be able to communicate TCP PSH or similar.
> (The current CONNECT spec in the doc doesn't define this --- should it?)
>
> (Having some examples in one of the docs for one or more of these and how
> it gets used with END_SEGMENT would be valuable to new readers.)
>
> For why you might want END_SEGMENT in headers:
>
>     HEADERS (request headers)   +END_HEADERS
>     DATA
>     HEADERS (for attributes related to the data) +END_SEGMENT  +END_HEADERS
>     DATA
>     HEADERS (for attributes related to the data) +END_SEGMENT  +END_HEADERS
>     HEADERS (for request footers)  +END_HEADERS  +END_STREAM
>
>
>
>
>
>
> On Fri, Apr 18, 2014 at 4:48 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> On 18 April 2014 13:38, David Krauss <potswa@gmail.com> wrote:
>> > With an empty DATA frame, which is exactly how I’m doing my interface.
>> But
>> > it really sounds like a corner case. Metadata is much more likely to
>> occur
>> > at the beginning of a new message than later, or especially the end.
>>
>> The classic uses of trailing headers is for metadata that is based on
>> the entirety of the message like a digest or signature.
>>
>>
>
Received on Friday, 18 April 2014 21:29:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC