Re: END_SEGMENT and END_STREAM redundant

On 2014–04–22, at 2:14 AM, Roberto Peon <grmocg@gmail.com> wrote:

> I believe you're saying that, at the application-layer the application is notified of the end of a segment by the transformation of an END_SEGMENT bit in the protocol to an END_SEGMENT header visible to the application?

Yes.

> I think you mean that end-segment is represented as a header key with a special value in the reference set, and thus the index is special/becomes an opcode.

I’m less qualified to design this at such a level of specificity. But, I would think that there is no need for an index or ever purposely putting it in the header table or reference set. Under normal circumstances the bit is the only determinant of whether the header/symbol/event is delivered to the user. There’s no need to modify the HPACK algorithm or tables.

> They are currently allowed-- with HPACK, this would imply the same request was sent again, at least for HTTP.

OK, now I see the “Reference Set Emptying” flag… so, extrapolating my rule, an empty HEADERS frame with END_SEGMENT would repeat the previous headers but with the addition of end-segment (and no change to the table). Doesn’t sound very useful, but still harmless.

>   for k,v in headers:
>     if ":END_SEGMENT" == k:
>       hf.setBit(END_SEGMENT)
>     hf.appendEncodedHeader(HPACK.encodeHeader(k,v)) 

I would do this a bit differently. The bit encodes an empty (or perhaps a default) value, and HPACK should only be involved otherwise.

if “:end-segment” == k and “” == v:
  hf.setBit( END_SEGMENT )
else
  hf.appendEncodedHeader(HPACK.encodeHeader(k,v)) 

A similar change needs to branch around the data frame special case.

>   outputStream.append(hf)

Yep, the only real changes I’m proposing are:

1) The :end-segment key is reserved to HTTP. (Your pseudocode reminds me that the prefix colon already reserves a name from the application, but is :end-segment actually available to generalized APIs?)

2) An intermediary may translate the bit to an actual header field representation or vice versa, just as a convenient technicality.