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

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


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

> The confusion is possibly due to the reports in errata 4535 [1] and
> duplicate 4645 [2],
>
>
> [1] - https://www.rfc-editor.org/errata/eid4535
> [2] - https://www.rfc-editor.org/errata/eid4645
>
> On Tue, Sep 22, 2020 at 6:30 PM Alan Egerton <eggyal@gmail.com> wrote:
>
>> I'm a little unclear exactly how clients should behave upon receiving
>> PUSH_PROMISE frames in certain illegal states.  In particular,
>> sections 5.1 and 6.6 of RFC 7540 appear to state contradictory
>> requirements:
>>
>> +------------------------------+-----------------+-----------------+
>> | Client state                 |   Section 5.1   |   Section 6.6   |
>> +------------------------------+-----------------+-----------------+
>> | half-closed(remote)          |       S:SC      |       C:PE      |
>> |                              |                 |                 |
>> | closed (RST_STREAM received) |       S:SC      |       C:PE      |
>> | closed (END_STREAM received) |       C:SC      |       C:PE      |
>> | closed (RST_STREAM sent)     |    Ignore/P:?   |   Handle/C:PE   |
>> +------------------------------+-----------------+-----------------+
>> KEY
>> S: = Stream error
>> C: = Connection error
>> P: = Reset promised stream (error type not stated)
>> :SC = STREAM_CLOSED
>> :PE = PROTOCOL_ERROR
>>
>>
>> So, which is correct?  And where RST_STREAM has been sent, should the
>> PUSH_PROMISE be ignored or handled (beyond sending RST_STREAM for the
>> promised stream, in which case what should be the error type)?
>>
>>
>> The relevant extracts from Section 5.1 are:
>>
>> In "half-closed(remote)":
>>
>> > If an endpoint receives additional frames, other than WINDOW_UPDATE,
>> > PRIORITY, or RST_STREAM, for a stream that is in this state, it MUST
>> > respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.
>>
>> In "closed":
>>
>> > An endpoint that receives any frame other than PRIORITY after
>> > receiving a RST_STREAM MUST treat that as a stream error (Section
>> > 5.4.2) of type STREAM_CLOSED. Similarly, an endpoint that receives any
>> > frames after receiving a frame with the END_STREAM flag set MUST treat
>> > that as a connection error (Section 5.4.1) of type STREAM_CLOSED,
>> > unless the frame is permitted as described below.
>>
>> and
>>
>> > An endpoint MUST ignore frames that it receives on closed streams
>> > after it has sent a RST_STREAM frame.
>> >
>> > [deletia]
>> >
>> > An endpoint might receive a PUSH_PROMISE frame after it sends
>> > RST_STREAM. PUSH_PROMISE causes a stream to become "reserved" even if
>> > the associated stream has been reset. Therefore, a RST_STREAM is
>> > needed to close an unwanted promised stream.
>>
>>
>> And from Section 6.6 PUSH_PROMISE:
>>
>> > A receiver MUST treat the receipt of a PUSH_PROMISE on a stream that
>> > is neither "open" nor "half-closed (local)" as a connection error
>> > (Section 5.4.1) of type PROTOCOL_ERROR. However, an endpoint that has
>> > sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE
>> > frames that might have been created before the RST_STREAM frame is
>> > received and processed.
>>
>> -- Alan
>>
>