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

Re: #549: END_STREAM flag on CONTINUATION

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Mon, 21 Jul 2014 12:10:56 +1000
Message-ID: <CACweHNBEOH0cn3eQS6UxkV1=EP8YE-ZDh0cv-uR9x40t=C6kLA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 21 July 2014 05:47, Mark Nottingham <mnot@mnot.net> wrote:

> <https://github.com/http2/http2-spec/issues/549>
>
> Any further discussion? Could we address the issue that people have by
> clarifying the text, perhaps?
>

Words would really help. I'm not sure what words to suggest, though. Maybe
in ยง4.3 at the end of: "This allows a header block to be logically
equivalent to a single frame." add a nota bene reference to the END_STREAM
flag on HEADERS frames.

Another suggestion, which is a little bit drastic, might be to remove Flags
from the general Frame Format, and instead have each frame description
include its own Flags field (if it needs one).

My personal confusion came from the fact that an incoming DATA[END_STREAM]
basically means "close for reading," so when I saw that HEADERS also has
END_STREAM, occupying the same bit, with the same description, I assumed it
was the same flag. Thus I overlooked the subtlety whereby
HEADERS[END_STREAM] depends on END_HEADERS.

If the DATA Flags and HEADERS Flags had occupied clearly different
namespaces, I wouldn't have been as surprised. It would also help to
explain why there's no registry for flags, even though they appear to be
semi-universal (e.g. 0x4 always means END_HEADERS, 0x8 always means PADDED,
etc.; 0x1 being the exception, meaning either END_STREAM or ACK)

Incidentally there's an aesthetic appeal to making the generic frame header
64 bits, and we could save a byte on some of the administrative frames.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/
Received on Monday, 21 July 2014 02:11:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC