Re: END_SEGMENT and headers

On 2014–04–17, at 7:46 AM, Jeff Pinner <jpinner@twitter.com> wrote:

> For a frame with the END_SEGMENT flag CLEARED, the HEADERS/CONTINUATION frame sequence would still need an END_HEADERS flag set, so in this case they are not equivalent. In this case, combining the flags would be inserting a segment boundary where none previously existed.

My intent was only to represent them by the same bit, not to merge the semantics. (I didn’t think it would make an actual difference, but notionally having two different flags is just easier to understand.) However, as I noted in reply to Roberto, an intermediary should not coalesce data across a header anyway although this doesn’t currently appear to be required.

Considering that:

1. An empty data frame with END_SEGMENT set, adjacent to a headers sequence, is semantically the same as setting END_SEGMENT in the HEADERS frame, and

2. A headers sequence must flush the data stream if it is to appear to be anywhere in particular, 
 
No expressive power is lost in the protocol by setting END_HEADERS = END_SEGMENT = 2, removing END_SEGMENT from the HEADERS frame, and having intermediaries treat them with equivalent semantics wrt fencing/flushing.

Received on Thursday, 17 April 2014 00:59:28 UTC