Re: END_SEGMENT and headers, #2

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