- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 18 Jun 2013 11:53:57 -0700
- To: Jeff Pinner <jpinner@twitter.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
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 between END_MESSAGE and END_HEADERS. 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 18:54:24 UTC