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 :) -=R On Tue, Jun 18, 2013 at 11:53 AM, Martin Thomson <martin.thomson@gmail.com>wrote: > 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 20:42:45 UTC