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

Re: END_SEGMENT and headers

From: David Krauss <potswa@gmail.com>
Date: Thu, 17 Apr 2014 08:58:45 +0800
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <93CB6AEA-92E5-46CE-AFF5-C4635C1FCF51@gmail.com>
To: Jeff Pinner <jpinner@twitter.com>

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

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