- From: David Krauss <potswa@gmail.com>
- Date: Sat, 19 Apr 2014 04:12:35 +0800
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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