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

Re: END_SEGMENT and headers, #2

From: David Krauss <potswa@gmail.com>
Date: Sat, 19 Apr 2014 04:12:35 +0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <32172F4C-68F2-4EFF-94B6-86CB20315664@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

On 2014Ė04Ė19, at 4:03 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 18 April 2014 12:02, David Krauss <potswa@gmail.com> wrote:
>> Iím designing an interface and canít bring myself to expose which type of frame defined the segment boundary. END_SEGMENT in HEADERS will just look like an empty data frame.
> 
> I'm not sure that I would expose segments myself.  Depends on whether
> you have an actual use for them.  

Itís for a generic library which is intended to support any protocol that could be layered on HTTP/2.

> Breaking a read() or event when you
> see END_SEGMENT or any HEADERS frame would probably work if your
> intent is to maintain segment breaks.

Yes, it seems that HEADERS practically requires END_SEGMENT semantics whether or not the bit is set. The bit is then only informative to the application which can query it, but what are the semantics of that corner-case query?

Not to beat a dead horse, but I think that bit should go. Data frames alone provide exactly enough END_SEGMENT flags.
Received on Friday, 18 April 2014 20:13:10 UTC

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