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

Re: Issue re. HTTP2 STREAM and HEADER block use same end bit polarity

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 18 Jun 2013 13:42:18 -0700
Message-ID: <CAP+FsNcDHpRiR6Pp60wRrGoofw-aU-1ThGBFJyxqhiBNF9bt9w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Jeff Pinner <jpinner@twitter.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
END_HEADERS indicates the end of a header block.
END_MESSAGE indicates the end of a message, which could be metadata only,
or it could be metadata+data.
END_MESSAGE is necessary because END_HEADERS is insufficient to indicate
the end of a message. It would only be sufficient if we knew that messages
were only headers.

END_MESSAGE should not be allowed on any headers frame where END_HEADERS is
not true.

I see Jeff replied before I got this email sent.
What he said too :)

On Tue, Jun 18, 2013 at 11:53 AM, Martin Thomson

> On 18 June 2013 11:39, Jeff Pinner <jpinner@twitter.com> wrote:
> > A suggestion for the HEADERS frame flags that incorporates "FINAL",
> > "MSG_DONE", and changes the polarity of "CONTINUES:"
> >
> > 0x1: END_STREAM - indicates that this frame is the last the endpoint will
> > send on the identified stream.
> > 0x2: END_MESSAGE - indicates that this frame comprises a message
> boundary.
> > 0x4: END_HEADERS - indicates that this frame marks the end of the encoded
> > header block.
> I like this generally, however I'm struggling with the distinction
> I can appreciate the logical purity of the argument for a distinction,
> but I can't see a practical benefit to it.  END_HEADERS implies
> concatenation, but END_MESSAGE just ...ends?  I'm not sure then what
> you do with a sequence of frames that form a message, if you aren't
> concatenating them. Websockets APIs concatenate.
> If this is about the hard lock-out that we have when HEADERS are
> continued, that doesn't need a special signal, just some text.
Received on Tuesday, 18 June 2013 20:42:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC