Re: END_STREAM flag and trailing headers

Martin,

again apologies for raising this long after it was discussed.    I found
and read https://github.com/http2/http2-spec/issues/228.

However, if I have this right, this now means that a PUSH_PROMISE, must
have data?    I don't see why that should be, as it may be that a server
discovers needs to push 30x redirects.

I have to say I don't fully understand what issue an intermediary would
have if it ignores push promises that do not have data?    But surely it
would be better to find a fix for that rather than complicate END_STREAM,
which should be a very straight forward flag

Actually I think that it is poor protocol layering to have to interpret the
type of a frame in order to workout stream boundaries.    END_STREAM should
be a flag available on all frames regardless of type. A stream should
exists from the first frame sent with its ID until a frame with the
END_STREAM flag set.  No frame types need to be considered.      Sure that
allows invalid sequences of frame types, but then there will always be
invalid sequences of frame types.

It is going to be a real pain in the future if every time a new frame type
is introduced we have to go back and work out what that means for stream
creation/destruction.

cheers



On 7 May 2014 19:51, Martin Thomson <martin.thomson@gmail.com> wrote:

> 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.
>



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.