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

Lucas Pardue <> Tue, 22 September 2020 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78A413A1966 for <>; Tue, 22 Sep 2020 13:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.771
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OYc3O-jZ0WdU for <>; Tue, 22 Sep 2020 13:11:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E7F73A194B for <>; Tue, 22 Sep 2020 13:11:55 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kKobT-0003BN-JH for; Tue, 22 Sep 2020 20:09:31 +0000
Resent-Date: Tue, 22 Sep 2020 20:09:31 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kKobR-0003AF-MQ for; Tue, 22 Sep 2020 20:09:29 +0000
Received: from ([2a00:1450:4864:20::633]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1kKobQ-00072A-7u for; Tue, 22 Sep 2020 20:09:29 +0000
Received: by with SMTP id gx22so15596422ejb.5 for <>; Tue, 22 Sep 2020 13:09:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=birlzK8JzTPusb8CiqYggN8GRA4B1PDBEOM3t3nQjFA=; b=ug/s+GR8bo5gTQx4daX68Sz0QkhE5cfeLeutpGDoRMZXN67blV/e1Yk9gd+VSIS3/G 8uJCGlA+vrL/Z7HnRYsWt2VciAdJJA6xJ9iL72Hh4K5uRc9PInd9mAEU5Xi282Z/GQfb Ee3Mb1VF7Y69/aXchI2tf1Oxf7K4YWjxyfGFXvHaepB1ix+VcOAKS3mmwV67kt1QcxYy fbXdXpNyghai/9MC6YEy8zjGNuoKmLAWDSV/ZH/RGz5ENQKwysjYUnhJmsQmZ47WNwdz 2Tbthl04Ic7T41mqPgm4m0XP2z6NqauSnIgkspoyCdsmUcFkOFOrf8FvZVhjkN4hGgM7 I1hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=birlzK8JzTPusb8CiqYggN8GRA4B1PDBEOM3t3nQjFA=; b=R1+qvbgxAEBG4lXOmswJFrzJCo3Cxf0KGUUZ2dWJnqsUoho8ozGYDHy8cMI8yCvDuY BxKMAw+29he5Hpsg+DEZE2FOBPL7+/x/gExVoLPfnuMR4p7baVfpQsDv6coj1eq48pyP 1hiZ+QvLTvG7IocHlJtdPgsjAYe+SZgb01LTcvf4GPFP8vsYr90stoTL5R0tdPXsM/H8 +tRuPPpBHstH8XBhCICBB1+UE3GHKSSZVDf8XQxOtgTTV1qpD5RJoyKZ57cOjeg2gEMK 2hE47ZJ/3HerXfMPOqDharzQR8rY1zFcytb2CCL3KgKR3lmApOhgtTthpWVyVjjZJOkv iIwA==
X-Gm-Message-State: AOAM533E87nWmqyVkOzkKPriwdZ3dmYujq7mhmzvEQoszfsvKK+eeK6h LPB2buAbIyylYESO8RMuF9UKMdEjwjLOK7tP3Cz/gno+EuI=
X-Google-Smtp-Source: ABdhPJwMWvhnQuRLPSWDKMpUf/nj0GuoD1e+X6mT7kscxKgjOFsuThWAUsbOFwK3B+Xg1oFwOhYIaJ3coJV9RZ7CXgY=
X-Received: by 2002:a17:906:3ac5:: with SMTP id z5mr6868773ejd.46.1600805356856; Tue, 22 Sep 2020 13:09:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Tue, 22 Sep 2020 21:09:05 +0100
Message-ID: <>
To: Alan Egerton <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000a6676005afec8a05"
Received-SPF: pass client-ip=2a00:1450:4864:20::633;;
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Scan-Sig: 1kKobQ-00072A-7u ebe27232b975d83b4533cb2db1fe72af
Subject: Re: HTTP/2 client behaviour on receiving illegal PUSH_PROMISE frames
Archived-At: <>
X-Mailing-List: <> archive/latest/38058
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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