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

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 22 September 2020 21:06 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 2F3193A08F5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Sep 2020 14:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.771
X-Spam-Level:
X-Spam-Status: No, score=-2.771 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] 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 feSsEZtaiGXg for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Sep 2020 14:06: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 6D5EB3A08DE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Sep 2020 14:06:03 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kKpRv-00007H-Hx for ietf-http-wg-dist@listhub.w3.org; Tue, 22 Sep 2020 21:03:43 +0000
Resent-Date: Tue, 22 Sep 2020 21:03:43 +0000
Resent-Message-Id: <E1kKpRv-00007H-Hx@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 <lucaspardue.24.7@gmail.com>) id 1kKpRu-00006P-4e for ietf-http-wg@listhub.w3.org; Tue, 22 Sep 2020 21:03:42 +0000
Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1kKpRs-0003kI-5w for ietf-http-wg@w3.org; Tue, 22 Sep 2020 21:03:41 +0000
Received: by mail-ed1-x52e.google.com with SMTP id t16so17592190edw.7 for <ietf-http-wg@w3.org>; Tue, 22 Sep 2020 14:03:39 -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=SoTXYP8eZmLRFg5BUs/Xe/erutjI/egm3Z0nTgC+KKw=; b=c6U+nNMwfU2J+gUMexgkh6h6AdXfOTiEqGoHvSLVhklXwYBQ5r8tkOhPIt8AG9xXWj MvQg8eOMkl2pzyATcqLol89sikn7ejLdErDIaM69K2pY69Il+w9uLAiFudDSsu/zOeSP 550RXXTQWWegkK6llmlJQlBhgiygR/Q2I211I6MYv9IHdQ4a0KS4Mxv/hIXpSu/WjNui 5782M17ZESAbvsG13Pj496PzGmxi580KXb2qAXP2YoWcJKO1TbVIiuuFPuR0jA+3NJFR 83Yoi8ryhNgtJQfYwPZgQv6gQGHGgOd5rIzYOXxVdF10G8Pf/bqUfJANSNZYHgR5FvRk VvGA==
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=SoTXYP8eZmLRFg5BUs/Xe/erutjI/egm3Z0nTgC+KKw=; b=KLAx+cGcQvBC0hb2mCWCygUyiEcryE+elvJfIduGGRpVuwYLcX3jk+XQJ6qCx8G8Eo rfPdW+BiugwrSNv8Y0/pRKNy9Mm6LWkfyTngyVVrXO0YkKOKyqoHG+1zXRncJUbvRwnw BQcm2/jMGdfNMHxClQRsaXAFYYS0hDaKxfUiXdGjXm6B05mbM2r3wwXt+6lLe1TGtbZ1 QDnrQ+OxuR6rZC6NRuTFnl/XpzXrKnDlDTm2/AzIp8MlGRdC9u9pHDInrWUw6X1z/81S dy0Oh0P65MTtLLeSH9hT4x6fLFYKkAFDbtSa6tepJR9boBTq4y6MqmDuttYBdeJ9DAb/ sh6w==
X-Gm-Message-State: AOAM530GRhPpDrXOYsiBV06v8AsZrQDbXRl1+uKu3HBJeZQNqy4JRP3R Nd5pbyn7uwwvJ6Fw7gDFvQv9TcRBb3KYq4JRHzKKr10H
X-Google-Smtp-Source: ABdhPJzCwsLRPVij4PmwCN+zrRSNv8MxE2SxlFMI9hKn8VzWwTK8XkNj9fuPljr/F9Ox6Cpsv88yJKXzhDfWc6BitVU=
X-Received: by 2002:a50:c051:: with SMTP id u17mr6262668edd.39.1600808608951; Tue, 22 Sep 2020 14:03:28 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CA+phaec3g5YdyY29OAjSg4QXh62EPRsf3FpdQ09DLU+Ufytb3A@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 22 Sep 2020 22:03:17 +0100
Message-ID: <CALGR9oZuBxQieo50fb+EpbXAu38=FeTE33qxjEAmBS6+9pVR0Q@mail.gmail.com>
To: Alan Egerton <eggyal@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000007d731205afed4c81"
Received-SPF: pass client-ip=2a00:1450:4864:20::52e; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-ed1-x52e.google.com
X-W3C-Hub-Spam-Status: No, score=-7.8
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_ENVFROM_END_DIGIT=0.25, 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_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1kKpRs-0003kI-5w 92fec25d841a9fe8cf250f2a65f3a845
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/CALGR9oZuBxQieo50fb+EpbXAu38=FeTE33qxjEAmBS6+9pVR0Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38060
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>

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