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

Alan Egerton <eggyal@gmail.com> Tue, 22 September 2020 19:40 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD93A0B88 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Sep 2020 12:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.77
X-Spam-Level:
X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ9Cxpw7YVY7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Sep 2020 12:40:56 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0CF3A0B52 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Sep 2020 12:40:56 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kKo7R-0002eI-7I for ietf-http-wg-dist@listhub.w3.org; Tue, 22 Sep 2020 19:38:29 +0000
Resent-Date: Tue, 22 Sep 2020 19:38:29 +0000
Resent-Message-Id: <E1kKo7R-0002eI-7I@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <eggyal@gmail.com>) id 1kKo7O-0002dV-RU for ietf-http-wg@listhub.w3.org; Tue, 22 Sep 2020 19:38:26 +0000
Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <eggyal@gmail.com>) id 1kKo7N-0000UX-0f for ietf-http-wg@w3.org; Tue, 22 Sep 2020 19:38:26 +0000
Received: by mail-pg1-x52e.google.com with SMTP id k133so8052770pgc.7 for <ietf-http-wg@w3.org>; Tue, 22 Sep 2020 12:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jBvOC2CC1IE07bIlcYwc3ybXBBMZNvRALBT0ETbqepw=; b=i6mKnG5+//9bP7yeY6mwTb7NR/GIKzBe13PJDvvkIf222UxIrNNNsCkHBd8kqjZgKH 0Fr++jUWe3NJN4YannMiJzU8z8/VH731z7+HfymMi8wvPv9/FDTouFQr7ztT5kjmg4ag 9oAGWaml7kbKic/DXGvpteFsZa27sr4/O/NAU+MVtAnSmSQt64vmhGHk5UxqUSzN5lWB xB+JNTIn/wu0xtjTq46L7frz31jiPzEXAjOGLEFYZRmdO6/+xI6RyzlK2dLB5ujcie+m mZMO3u+lpJ4uzpwfLNvAyu3twvTNpaKNZfCoU8N+xmBKOJvJOJPfxdwlDrAGIDcNiHTa IjRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jBvOC2CC1IE07bIlcYwc3ybXBBMZNvRALBT0ETbqepw=; b=Pj+zpEBs1SAOXyNhSnvxOqPhSjPp9nZ+kqUpXUOPPEEU5s1wi12DvVxLAHeUZQjuJd 7OFAQUm06ZKGseswAoN6NtQWryzm6AliAOqfbZNZg2Nnr6SbRGCt1aqfDvOwiqOmXJP+ /mfX3VUfrhEMf1+NINJBRtJbL8X9lzPOFrlzU3Gs5vjzse7AVOwr6JqqGVA9pOMmFZsX toObzE4qxPgpiqjCNN+Ueht9sBEDbMuFGXmk23kuNmYgsMkMEzhVwkyqNpVieIznBEDB 5SL8/PetdDsDUZBERK4sUbcA6vOakWD/VtIV6jC4s6ERGq0fG66rNBTVNVnEtB5flNXW FF2A==
X-Gm-Message-State: AOAM5339MVTgXaW8qd+TkHcgy5SsVD6h6lyaJZwYDDovPGTuwBBBKYfv g+nT8KXpQV08R2nK66hK7CNmmYe1seI0RzBgafQ=
X-Google-Smtp-Source: ABdhPJy7tWoBnIlVDffMKqM+WJ0aO96q1Ysa2nIx9whbOT6LrgPI1JndxNB5kRQDVYVe2PpM44zxkMGAt1kKgeWhzk8=
X-Received: by 2002:a62:d456:0:b029:13c:1611:66c2 with SMTP id u22-20020a62d4560000b029013c161166c2mr5432215pfl.13.1600803493774; Tue, 22 Sep 2020 12:38:13 -0700 (PDT)
MIME-Version: 1.0
References: <CA+phaeeHSjyKx8Dv_DqUmL=1TuYyahsFEW364TQT3Kw5j4U5xw@mail.gmail.com> <CALGR9oZLp+RBZCaCr-Q4uBX7UGieSavizxWLcw3gmHpcuz8k1g@mail.gmail.com>
In-Reply-To: <CALGR9oZLp+RBZCaCr-Q4uBX7UGieSavizxWLcw3gmHpcuz8k1g@mail.gmail.com>
From: Alan Egerton <eggyal@gmail.com>
Date: Tue, 22 Sep 2020 20:38:02 +0100
Message-ID: <CA+phaeeaeL+64TyrQgp3+=wDiDbtxcTYqzSzQN2PN34WfRadsQ@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000009a090905afec1b57"
Received-SPF: pass client-ip=2607:f8b0:4864:20::52e; envelope-from=eggyal@gmail.com; helo=mail-pg1-x52e.google.com
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1kKo7N-0000UX-0f bee21c1c35f6a48673cd6a5dcd3477d1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 client behaviour on receiving illegal PUSH_PROMISE frames
Archived-At: <https://www.w3.org/mid/CA+phaeeaeL+64TyrQgp3+=wDiDbtxcTYqzSzQN2PN34WfRadsQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38057
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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