Subject: END_SEGMENT and headers, #2

From: David Krauss <[email-masked]>
Date: Sat, 19 Apr 2014 03:02:03 +0800

Is an intermediary (or application interface) allowed to move an END_SEGMENT flag from a HEADERS frame to the preceding DATA frame or from DATA to a succeeding HEADERS? It’s a redundant coding.

I’m designing an interface and can’t bring myself to expose which type of frame defined the segment boundary. END_SEGMENT in HEADERS will just look like an empty data frame.

I still think END_SEGMENT should be dropped from HEADERS.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 13:03:25 -0700

> I’m designing an interface and can’t bring myself to expose which type of frame defined the segment boundary. END_SEGMENT in HEADERS will just look like an empty data frame.

I'm not sure that I would expose segments myself.  Depends on whether
you have an actual use for them.  Breaking a read() or event when you
see END_SEGMENT or any HEADERS frame would probably work if your
intent is to maintain segment breaks.

---

From: David Krauss <[email-masked]>
Date: Sat, 19 Apr 2014 04:12:35 +0800

On 2014–04–19, at 4:03 AM, Martin Thomson <[email-masked]> wrote:

> you have an actual use for them.  

It’s for a generic library which is intended to support any protocol that could be layered on HTTP/2.

> Breaking a read() or event when you

Yes, it seems that HEADERS practically requires END_SEGMENT semantics whether or not the bit is set. The bit is then only informative to the application which can query it, but what are the semantics of that corner-case query?

Not to beat a dead horse, but I think that bit should go. Data frames alone provide exactly enough END_SEGMENT flags.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 13:23:52 -0700

> Not to beat a dead horse, but I think that bit should go. Data frames alone provide exactly enough END_SEGMENT flags.

Roberto described why he wanted it: to be able to finish a segment
with a HEADERS frame.  I don't see how you can address that need
without the bit.

---

From: David Krauss <[email-masked]>
Date: Sat, 19 Apr 2014 04:38:47 +0800

> with a HEADERS frame.  I don't see how you can address that need

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.

I can see translating HTTP-like transactions to segments, and you would END_SEGMENT after each response. But sending an empty data frame for an empty response body is only 8 bytes. In the old currency that only buys you the string "HTTP/1.1” :v) .

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 13:48:16 -0700

On 18 April 2014 13:38, David Krauss <[email-masked]> 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.

---

From: David Krauss <[email-masked]>
Date: Sat, 19 Apr 2014 04:53:15 +0800

> the entirety of the message like a digest or signature.

Sure. So back to my question, is an intermediary allowed to shift an END_SEGMENT from a header to an empty data frame?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 14:05:19 -0700

> Sure. So back to my question, is an intermediary allowed to shift an END_SEGMENT from a header to an empty data frame?

I'd have thought not, since that effectively moves the HEADERS frame
to another segment.

---

From: Erik Nygren <[email-masked]>
Date: Fri, 18 Apr 2014 17:21:48 -0400

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 18 Apr 2014 14:29:26 -0700

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 <[email-masked]> wrote:

> 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
> * 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?)
>