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

Re: END_SEGMENT and END_STREAM redundant

From: David Krauss <potswa@gmail.com>
Date: Tue, 22 Apr 2014 08:31:08 +0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <B5ACF867-91AD-4A02-8969-DDCEF9D4AF23@gmail.com>
To: Roberto Peon <grmocg@gmail.com>

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.


Received on Tuesday, 22 April 2014 00:31:45 UTC

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