Re: END_SEGMENT and END_STREAM redundant

There might be some misunderstanding here… the paragraph beginning “One approach would be…” in my earlier message was intended to be separate from other suggestions I’ve made. (Sorry there have been so many, but this one seems like a good compromise.)

Fleshing out the idea:

1) The end-segment symbol is transported by an end-segment header.

2) The end-segment header may be encoded (with an empty or default value) by the END_SEGMENT bit. Applications don’t even need to know about this. Otherwise it’s just a normal header.

3) The END_SEGMENT bit is decoded after other HPACK decoding, equivalent to a literal encoding not added to the header table. (Perhaps I’m missing some details here… in implementation terms, it’s simply not part of the decoder but tacked on afterward.)

In practice, regular HPACK encoding of end-segment would just be monkey business. The user could give it a value, put it in the reference set, etc. It would be weird but I see no ill side-effects. It’s not so different from forgoing any other compression method of HPACK.

4) The end-segment symbol (as treated distinctly from the header) should be processed after any other headers or data in the frame, although this is only an application-level notion.

5) If empty HEADERS frames aren’t allowed, an end-segment header alone would (optimally) be sent as an empty DATA frame. It should be simple to specify that END_SEGMENT doesn’t render a frame “non-empty” per HPACK restrictions.


The reasons to do it are:

1) General header-oriented APIs can provide the end-segment symbol. Programs can make one less API call and avoid adding a special case for the special end-segment metadata, which after all isn’t actually special except in its wire representation. Of course, this doesn’t preclude having a dedicated interface for end-segment as well.

Put simply, “conceptual uniformity and canonicalization.”

2) Remove the unintended reliability of the framing-layer protocol to prohibit application usage. Separate it from the application layer without any “thou shalt not” language.

3) Easy to retrofit onto existing implementations. No new intermediary processing is required. An HTTP/2 response maps more cleanly to a sequence of HTTP/1.1 responses.


On 2014–04–21, at 12:34 PM, Roberto Peon <grmocg@gmail.com> wrote:

> An empty HEADERS frame may not actually convey zero metadata, if HPACK is being used.
> 
> If one wishes to overload HEADERS to signal END_SEGMENT, then one must:
> 1) ensure that applications do not use the same keyspace as the reserved key.
>    - can be done, but "smells bad"
> 2) ensure that the compressor state is modified properly to convey *only* the key
>    - might hurt a bit, as this essentially renders the compressor useless...
> 3) ensure that an empty metadata frame does not convey some meaning.
>    - Not guaranteed today: an empty METADATA frame might convey some meaning at the application layer.
> 
> END_SEGMENT as a bit avoids these problems.
> 
> I agree that we might want more text in there to clarify what should be visible to the application (i.e. *not* frames, but rather metadata, data, end-segment, end-stream), subject to editor approval.
> 
> -=R