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

Mike Bishop <mbishop@evequefou.be> Tue, 22 September 2020 22:13 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 1CA803A1A2D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Sep 2020 15:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.671
X-Spam-Level:
X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 ENM4ITDS-Q68 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Sep 2020 15:13:04 -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 813953A0A9B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Sep 2020 15:13:04 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kKqUb-0007Vx-MU for ietf-http-wg-dist@listhub.w3.org; Tue, 22 Sep 2020 22:10:33 +0000
Resent-Date: Tue, 22 Sep 2020 22:10:33 +0000
Resent-Message-Id: <E1kKqUb-0007Vx-MU@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mbishop@evequefou.be>) id 1kKqUZ-0007T3-1I for ietf-http-wg@listhub.w3.org; Tue, 22 Sep 2020 22:10:31 +0000
Received: from mail-bn8nam12on2099.outbound.protection.outlook.com ([40.107.237.99] helo=NAM12-BN8-obe.outbound.protection.outlook.com) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mbishop@evequefou.be>) id 1kKqUW-0002bm-Bt for ietf-http-wg@w3.org; Tue, 22 Sep 2020 22:10:30 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RchaU7cfiesydJiC7ungf0tUlo/e+OslvQnQGvrnZUj5VG8UMn367L0Cq2X8q3QPC4YzLIbo59owp2MjdK9EwRVUbzAZoqZua7pvNdKb7Oi3P9nQwcs84Q3PKDpHkL9dTyyQnTkj1dsebDwhykmmGk3yEGo4jXXCdtDoKyNJS7V3dtt/hYQkGKmu5MuuQ71mfJ4OTYzL1HNcimxmb2t0DUCEA45Cli/ZJeAvY8R/86fiJx3or9vrbU/fVEYFEC6Le3GRaand3l8fU87DcG7QuuNPP/20tvnkDx//wrc3AHvOpRcgnbniH/srzufZIXaILnzdlMEJv7OMNoYXt0aP8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yEHSBsQi9ol8tH7Bzc1ztHIgF7Y8HqOP/3czatRVNkI=; b=HxK2z5fU3Zodx7UZ+aG/9uIZHs0yJzuX4gPnzKgO2fWktGuBrNeTIa/8l55cQ2oazhKvFuzzTpNepCdW8TVeeK2+nUE7tyKSGXTAO9TUEhMIdFNJcbngYHDh2AMasiYY06DfEyQLIATatLcnKzYGBXC2W4YN64Q0xRuC6uhP+S4yZx/vHxRNi878Fe8LpKPo/ZKHR9Ey9hvs1/ZFuU+QCmZ7Bi1Rt7fToJvJjPzBy3X5JK0eTy3sL6n9QTSeArHWcz36FOZEJr5S95q6qXN7sKsalVm8a+gQvnoJziPJ9n4TQEUX9n6zzNi/8O4YOqPT9n9JCKELY5b/hPBvYyqYbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yEHSBsQi9ol8tH7Bzc1ztHIgF7Y8HqOP/3czatRVNkI=; b=XjQuak0OAlngBIKfC6o6wmUPr5xhH/4B0EeDEu4Kdmt/mXqziE+0WYU3I26iyd/Q6IrMBj81weuEeBJqTSGED22BxeqAvsX5PsIniOvyzpFFZi20qFVufhBjrmXf410eYyoM0/Fzu00kft/y5cW5LwPIzr+IDuC7mG4vHnMwrcE=
Received: from CH2PR22MB2086.namprd22.prod.outlook.com (2603:10b6:610:8c::8) by CH2PR22MB2038.namprd22.prod.outlook.com (2603:10b6:610:5c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Tue, 22 Sep 2020 22:10:15 +0000
Received: from CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::2827:5a3c:11db:7a55]) by CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::2827:5a3c:11db:7a55%4]) with mapi id 15.20.3391.011; Tue, 22 Sep 2020 22:10:15 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>, Alan Egerton <eggyal@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: HTTP/2 client behaviour on receiving illegal PUSH_PROMISE frames
Thread-Index: AQHWkQX4smhBD4KonUKXsV0NNCu9Aql09z6AgAAWegCAAAitgIAACUeAgAAF3oCAAA+uwA==
Date: Tue, 22 Sep 2020 22:10:15 +0000
Message-ID: <CH2PR22MB20869D12084628CDF0F0876FDA3B0@CH2PR22MB2086.namprd22.prod.outlook.com>
References: <CA+phaeeHSjyKx8Dv_DqUmL=1TuYyahsFEW364TQT3Kw5j4U5xw@mail.gmail.com> <CALGR9oZLp+RBZCaCr-Q4uBX7UGieSavizxWLcw3gmHpcuz8k1g@mail.gmail.com> <CA+phaeeaeL+64TyrQgp3+=wDiDbtxcTYqzSzQN2PN34WfRadsQ@mail.gmail.com> <CALGR9oYU=JzkZuVYwvY87hycUgy1qKrWV50VF49cfM_A8pntMw@mail.gmail.com> <CA+phaec3g5YdyY29OAjSg4QXh62EPRsf3FpdQ09DLU+Ufytb3A@mail.gmail.com> <CALGR9oZuBxQieo50fb+EpbXAu38=FeTE33qxjEAmBS6+9pVR0Q@mail.gmail.com>
In-Reply-To: <CALGR9oZuBxQieo50fb+EpbXAu38=FeTE33qxjEAmBS6+9pVR0Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=evequefou.be;
x-originating-ip: [72.49.212.17]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f94ba0fe-6fda-416c-1db6-08d85f4448d9
x-ms-traffictypediagnostic: CH2PR22MB2038:
x-microsoft-antispam-prvs: <CH2PR22MB2038DB7B74731CF24B3355D9DA3B0@CH2PR22MB2038.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xxCrg0iq6dFbxVocyCCyJSkMu62dXg4RdPTcRo26Swc3URfAshQ1ANO199q7X1/90rN5mscbxlkD5CBUfvzovK8+4Amjd2C88WSn2uIjeyv4hvoSBdMDaQxpfyK0holqME/3HwPWOBvBycNROAtqjLnvALq+B0okWeoekUnIFLRsxW54k5irK9XjHlPWA0lHdJw4af4M6gZCK2iNEJPtmMxZUJcw6j6+ZE+jbR9ntRKBJN9CScPP/MumUZ0MgbItWRE58/dWrMmOXcuB5C9mnGc2Js+7Z9ysR25nqYTlyp216BpcdhQFE6yXKuGPlsqntFDwOuxmhZb78fgzi3fBow==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR22MB2086.namprd22.prod.outlook.com;PTR:;CAT:NONE;SFS:(366004)(136003)(396003)(39830400003)(376002)(346002)(2906002)(9686003)(5660300002)(478600001)(66946007)(52536014)(110136005)(55016002)(8676002)(4326008)(76116006)(33656002)(83380400001)(8936002)(316002)(66446008)(64756008)(186003)(86362001)(71200400001)(99936003)(66556008)(66476007)(66616009)(6506007)(26005)(7696005)(53546011);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata: idqQ+RXL6gNeSgsCt6ZEoSX3eW8Yyz+sCYeu/81TlG9U8uZ+WC0gcPbpP5biG56TXVMv5r23FU6n7pnQdExX7AwxF0KelJnTS163no06DtZuGF74WHiAFZA1JKgzwJkOKRN/k5zGG0vUs9vpfjuH9Dcaymex7/aqwVE4zOAI4j9mySKH/ZatMmRq1KhPOtjQZj2XvbC3TxNwblnFPPRM7ohPgeGBmD5CqfXnq1H2dD/2K6OCG3tF9RrhNQt0bPcy9KGs7P0EAoGFDHPu9z/7eOZV1Fg1hd1vprOXgK3JKUAVMS8+o9qNkRTZANhUOo1oGL9z+3/1Z2uPxmNSfMJHWGFIw0x5fzhVOZloVwOrVGdQIjlD6mwY1q4deRiQ50dsl58Bpf3P24TeDPLfPcJy7I2sL8xSQYAPUtkQjY2pmVj8IWiZv9XF9W5kdRg194pxh8/Lsn6UJn8maGrJZFjEm/oMjjzOZcP6CIczA0QdMI9v93YvnKUB/J5k0m2dVGwxRjWEaNXduJuuV77JSUvKMnRlCwBdQkvD/XUhLJCkqeDUqQf1xO2c+GeWtNY8ZkQ0/uUWguQncUS92ThBNlKnRLZKWzPQGrJCMtaAEf6oS5J3IPMQP0URwly3iLymNhezpYW1tP2Or6Q5QC5XJaIRtg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0035_01D6910B.9C0B1C90"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR22MB2086.namprd22.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f94ba0fe-6fda-416c-1db6-08d85f4448d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 22:10:15.6662 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hiU+07qWkoNRhlABcCaBR3AhW/YRxOTuTV39PhM/6d8iPWmzD1wj7lfcygty9WbNyU0Rz3/FgRrPnLtEZfLKWg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB2038
Received-SPF: pass client-ip=40.107.237.99; envelope-from=mbishop@evequefou.be; helo=NAM12-BN8-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1kKqUW-0002bm-Bt aef394acf0014385f6b44e3a41df01ef
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/CH2PR22MB20869D12084628CDF0F0876FDA3B0@CH2PR22MB2086.namprd22.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38061
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>

Section 6.6 says that you C:P-E (using your notation) for receipt of PUSH_PROMISE when they can’t have legally been sent; it has an exception to account for a race condition, and says that you “MUST handle” them.  So it doesn’t mandate anything in particular beyond handling as normal in that race condition.  I’d echo most of Lucas’s points; it doesn’t need to specify the error code for RST_STREAM, because you’re “handling” it normally.  If you don’t want it, use the error code you would routinely use for unwanted pushes.

 

However, you’re correct that receiving a PUSH_PROMISE in “half-closed (remote)” isn’t one of these race conditions; that means that the exception doesn’t apply in that case and the requirement to C:P-E applies in that scenario. 

 

It’s a bit odd that we require both a stream error and a connection error triggered by the same frame, but the ordering of those doesn’t matter; the connection is closed at the end either way.  I suppose my lawyerly answer is that a requirement to generate a stream error doesn’t preclude also treating it as a connection error, so this is merely a bit awkward and not outright wrong.

 

From: Lucas Pardue <lucaspardue.24.7@gmail.com> 
Sent: Tuesday, September 22, 2020 5:03 PM
To: Alan Egerton <eggyal@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTP/2 client behaviour on receiving illegal PUSH_PROMISE frames

 

My read is that 6.6 is a specialisation of the error conditions described in 5.1, therefore it might help to mention that in 5.1. Others might disagree.

 

As for RST_STREAM of the unwanted push, I'd say this is just as described in 8.2.2; either CANCEL or REFUSED_STREAM.

 

On Tue, 22 Sep 2020, 21:42 Alan Egerton, <eggyal@gmail.com <mailto:eggyal@gmail.com> > wrote:

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 <mailto:lucaspardue.24.7@gmail.com> > wrote:

 

 

On Tue, Sep 22, 2020 at 8:38 PM Alan Egerton <eggyal@gmail.com <mailto: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