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

Hi Lucas,

The situations I've described are absolutely illegal PUSH_PROMISE
frames—but sections 5.1 and 6.6 appear to disagree over what error handling
is appropriate in those situations.

-- Alan


On Tue, Sep 22, 2020 at 9:09 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

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