Re: HTTP/2 client behaviour on receiving illegal PUSH_PROMISE frames

On Tue, Sep 22, 2020 at 8:38 PM Alan Egerton <eggyal@gmail.com> wrote:

> Thanks Lucas, but I don't think either of those reports are quite the
> same: they both appear to concern the state transition from "idle" state on
> sending a PUSH_PROMISE (and that the spec can be misread as describing
> transitions from that state on receiving such frames); whereas I am
> concerned with the correct error handling on receiving an erroneous
> PUSH_PROMISE in the "half-closed(remote)" or "closed" states.
>
> -- Alan
>
>
oops I meant to say "possibly related" because this is about the handling
of push promises with respect to stream lifecycle. My 2c:

I might be squinting at the state machine wrong but I don't think it is
practically possible for the client to have a request stream in a
half-closed (remote) and receive a PUSH_PROMISE. Because the only way to
get a stream in that state is for a server to respond to a request with
END_STREAM set, before the client has sent END_STREAM or RST_STREAM. This
is an early response, which is allowed. But the server shouldn't be trying
to promise things after it closed the stream, that's a plain error.
Similarly, a server sending PUSH_PROMISE after RST_STREAM is also an error.

The odd case is when a client and server have a race about the stream being
closed due to the client sending RST_STREAM in the open state. "Closed
because I said so" is a bit different to "Closed because you said so". The
statement in 6.6 about "MUST handle PUSH_PROMISES" is trying to wiggle out
of the race condition.

Cheers
Lucas