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 >> >
- HTTP/2 client behaviour on receiving illegal PUSH… Alan Egerton
- Re: HTTP/2 client behaviour on receiving illegal … Lucas Pardue
- Re: HTTP/2 client behaviour on receiving illegal … Alan Egerton
- Re: HTTP/2 client behaviour on receiving illegal … Lucas Pardue
- Re: HTTP/2 client behaviour on receiving illegal … Alan Egerton
- Re: HTTP/2 client behaviour on receiving illegal … Lucas Pardue
- RE: HTTP/2 client behaviour on receiving illegal … Mike Bishop
- Re: HTTP/2 client behaviour on receiving illegal … Alan Egerton