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

Alan Egerton <> Tue, 22 September 2020 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D30E3A044A for <>; Tue, 22 Sep 2020 13:45:06 -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 zrF8QbT5MVVZ for <>; Tue, 22 Sep 2020 13:45:05 -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 096993A0417 for <>; Tue, 22 Sep 2020 13:45:04 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kKp7b-0005QG-H6 for; Tue, 22 Sep 2020 20:42:43 +0000
Resent-Date: Tue, 22 Sep 2020 20:42:43 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kKp7Z-0005PB-J5 for; Tue, 22 Sep 2020 20:42:41 +0000
Received: from ([2607:f8b0:4864:20::52a]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1kKp7Y-0002np-7J for; Tue, 22 Sep 2020 20:42:41 +0000
Received: by with SMTP id y1so12941047pgk.8 for <>; Tue, 22 Sep 2020 13:42:39 -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=rL98bpNOpKKp1h0BwMgxiDYJ+fu52wG3lD8Lt9QZHiY=; b=QSEcHZKiFBJoLRNs40W4Eoio8z3Nvsm9q7ivGuKnS1hEZYp7WnOV7ljWNNJTjWgYLa qB37smh8Q/5HZEK+hbOoOV0D+R/H4e+bjYKYOeFqoE4F22NT4Sb4ltwHwyivpDt+A/jw ZrGTIOxy4l0cT2H3KZEgBezVQl75oM9CyHcsYQfavUlh1FkTYdJutN/t2KhXQj6mQ5NW PCpGzhBKlcVZHJYz9qsGgvR/BbnZ5tLUljIlZrram+xLCyPBo3zIW0pocWBZNSS3Tjeo GrSfjmoFPzAmzx9NVAgTnWIeVedJh8XZ3CqpP1SCCywyLpPYuYh0RoLhUfP274yc7sel myKA==
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=rL98bpNOpKKp1h0BwMgxiDYJ+fu52wG3lD8Lt9QZHiY=; b=VR0YwTpaTylBDVXTPn6AWAb50jiuwGGZ2OPp8cDqWCzoK5MF9q2GZTlJWiFuSdMy20 +KOLZoLYGI1JDDynPdUhf5xWynsVMrmKadiWuhi/95u/WHGaB14YShPU+oFpBV2kL5nD Z9qg76334JOa4ukSKONKar0Rs3var8ngwJAwXaswkvKYZpfy+3nfFsPFBcgjamisOg1y 3QiMOQUyCeqXgTN012Cb542rUfsa4qsYLRjbptbEGySEqHzAqhSPeIxB0P5Tn9iyZ4JO URoBhR973yAlm1ojHgxqoR5jO8Wgro8eHvmS3judnMJr8sdQMF2ar+W8jQQhhlHRwH6B RqEg==
X-Gm-Message-State: AOAM533hnE1+UDvuI52tytsVq67qQSXUGkz28AID+rEnVgcsmoYGktvP Yc3egno1eTKaSDCXTs1o254srenEYOP7e1M9+rI=
X-Google-Smtp-Source: ABdhPJwuNhq5q1GsODZf5os3y+G0Z+BK890+KNP3zWMLGG2Ftymmv/YQ+Je9MTuXqvExVaOWXgnMTJOzK3AvAjE7LgA=
X-Received: by 2002:a63:5566:: with SMTP id f38mr4780789pgm.9.1600807348894; Tue, 22 Sep 2020 13:42:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Alan Egerton <>
Date: Tue, 22 Sep 2020 21:42:17 +0100
Message-ID: <>
To: Lucas Pardue <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000627fab05afed01ed"
Received-SPF: pass client-ip=2607:f8b0:4864:20::52a;;
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: 1kKp7Y-0002np-7J 42e4844770cef2ad856b6f0100bbbb73
Subject: Re: HTTP/2 client behaviour on receiving illegal PUSH_PROMISE frames
Archived-At: <>
X-Mailing-List: <> archive/latest/38059
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

> 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.
> Cheers
> Lucas