Re: END_STREAM flag and trailing headers

On 7 May 2014 07:27, Greg Wilkins <gregw@intalio.com> wrote:
> What is the reason for the multiple statements in the spec like:
>
>   A HEADERS frame bearing an END_STREAM flag can be followed by CONTINUATION
> frames.

There's basically two ways to roll this (I hope that you can infer my
shorthand correctly here...):

What we have is a formulation for a stream that looks like this:

H C C C(EH) D D D D D H(ES) C C C(EH)

We discussed the logical alternative, which was in the draft for quite
a long time:

H C C C(EH) D D D D H C C C(ES,EH)

The problem came about when we looked at the use of CONTINUATION
frames for PUSH_PROMISE.  If we wanted to do the latter, we would have
to permit the use of END_STREAM on CONTINUATION if it was used after
HEADERS, but prohibit it if it followed PUSH_PROMISE.

The solution we came to was what you see in the spec.

> As a side note that there is some confusion of the sequence of continuation
> frames ends with just and END_HEADERS flag, or does it need both the
> END_HEADERS and END_STREAM?  Should each of the CONTINUATION frames sent
> before the final one have the END_STREAM bit set?

CONTINUATION doesn't define an END_STREAM bit.

> It will be clear to any HTTP receiver that the stream is about to end
> because they have received a HEADERS frame after the initial headers and/or
> data, so having the END_STREAM bit set provides no extra information other
> than devaluing the clear meaning of the end of the stream.

That's not quite right, we permit the sending of additional HEADERS
frames, but they can be treated as line noise (i.e., discarded).  See
http://http2.github.io/http2-spec/#HttpSequence, which says: "Header
blocks after the first that do not terminate the stream are not part
of an HTTP request or response. "

> Currently we
> can only stop expecting more frames for a stream if ( we have seen
> END_STREAM seen on a HEADERS (potentially some frames ago)  && we receive
> END_HEADERS ) || (We received a DATA frame with END_STREAM) .

Correct, though it might be better to consider any CONTINUATION frame
as part of the HEADERS frame for the purposes of stream handling.
That simplifies the logic considerably.  That means that reading the
full header block will cause the connection to be blocked, but that's
a natural consequence of having oversized header blocks anyway:
nothing can be interspersed with CONTINUATION frames.

Received on Wednesday, 7 May 2014 17:52:20 UTC