Re: HTTP/2 and non-authoritative pushes

Ted Hardie <> Tue, 14 April 2020 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF75B3A0E60 for <>; Tue, 14 Apr 2020 13:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Status: No, score=-2.751 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.248, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=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 0B_GEQslzSFp for <>; Tue, 14 Apr 2020 13:11:00 -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 624ED3A0E53 for <>; Tue, 14 Apr 2020 13:10:59 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jORr3-0001eW-FO for; Tue, 14 Apr 2020 20:08:21 +0000
Resent-Date: Tue, 14 Apr 2020 20:08:21 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jORr2-0001aV-LR for; Tue, 14 Apr 2020 20:08:20 +0000
Received: from ([2607:f8b0:4864:20::22d]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jORqz-00046q-PD for; Tue, 14 Apr 2020 20:08:20 +0000
Received: by with SMTP id k133so10848351oih.12 for <>; Tue, 14 Apr 2020 13:08:17 -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=ekIAR1HOXXmvN1FGrbZ+8YO7HHacglQFaKEWoH2iCCA=; b=rLV1Cxra4xmc7r5eNXPDFuzDjLTnad2m2jRohPFwEj3ARwyfH/7WZ5DmeQ6nU9zfMP rvkFPxPRQk7dfYDUWUVCiP4wzClSHpWT4JknfxEJaWAsJ0OQnJYpERMpb4UGrb3AjYO3 kPPU5Th2QRRzi9UIBFiTSyu7ZdIt6hENu+1PmmxfjxJ6chGuVqs3aIfBXcALc+P3MmWJ LizMfXriKIk6L+UiDSqJgJIqSEB8CFHr2LuYtl/0LIneKnw1bSPHO3y2G+f4Hzehyu9y iUp8KRkHo5Xy1Hxdc3KZ4hnfpmrAjassGS1UF1TftpEj0liAf93yiwIHm6FrckcCn9+i V8TA==
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=ekIAR1HOXXmvN1FGrbZ+8YO7HHacglQFaKEWoH2iCCA=; b=gbGLC0AuD7sNZ7AreZV29LpQEBMWsxAoEhhM99IILQxCom05gVBeo/5tBUN+TT8FlL r1aXKTSX7d6nKHybwkkrDfeV4uuvx4UrWhItWeUyM6WiRbJGfeLQ1VFYsTdKEZxjcUzo WTwp/2S+GKb9YID4Xbkrxq5q4AJ0tCdeSA/cZ1N3eZZynV4sfkUxlsoh1Neqxm8JI75l Z9yNwOGoZSCNB/NQ3Mk11UNANQLXNKH0MgFi3+EL9Te74KaHXhDAWxA/OfFADsefwaL+ 7ad+VlhoB0i3F2RT1HZgmpe9nx4lfhDKvFZdyu8yjDC2/kHv/5O1xKhAIWbFZDli3PMH h0zg==
X-Gm-Message-State: AGi0Pub9vecA8cdDFQ76eyR+eCIynt2cqS6oNvWXqeNckJd90HC4NARL 2ZLUVZeceZf4wI8arMA6w6aGoeUce6Pk5FgEMj2r0fbeom4=
X-Google-Smtp-Source: APiQypLoqe9liSmLKvB3G2muRxl0Z15tMteCdP7LNg392ELFpN059uUNUZ0peJyDOXqlj2siLF+eo+CJDHoAlpSCL5g=
X-Received: by 2002:aca:fdd5:: with SMTP id b204mr9150472oii.167.1586894886594; Tue, 14 Apr 2020 13:08:06 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Tue, 14 Apr 2020 13:07:40 -0700
Message-ID: <>
To: Mike Bishop <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000002ef0305a345c284"
Received-SPF: pass client-ip=2607:f8b0:4864:20::22d;;
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_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jORqz-00046q-PD 975dfe8516fbfdd3a5b37ca1b47c59c2
Subject: Re: HTTP/2 and non-authoritative pushes
Archived-At: <>
X-Mailing-List: <> archive/latest/37506
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, Apr 14, 2020 at 12:42 PM Mike Bishop <> wrote:

> Secondary Certs issue #1088 leads back to an interesting bit in RFC7540.
> Section 8.2 says:
>    The server MUST include a value in the ":authority" pseudo-header
>    field for which the server is authoritative (see Section 10.1 <>).  A
>    client MUST treat a PUSH_PROMISE for which the server is not
>    authoritative as a stream error (Section 5.4.2 <>) of type
> Note that it doesn’t explicitly say which stream should be treated as
> being in error.  The simplest reading, since it’s an invalid PUSH_PROMISE,
> would be the stream on which the PUSH_PROMISE was sent.  However, the
> server and the client might not have the same view of what origins the
> server is authoritative for, for various reasons.  Given that, blowing up
> the *parent* request because of an invalid PUSH_PROMISE seems completely
> unreasonable as a response.  Should this indicate that it’s a stream error
> on the promised stream?

I think that would be in-line with the list discussion we had in the
context of (rejected) erratum 4535
That was not, sadly, captured with the erratum, but generally was inline
with the reading that an invalid action by the parent blows up the child
stream, not the parent (at least that's my reading).


> (In Secondary Certs, the draft currently requires that the server have
> sent the certificate for the origin it wants to push for prior to pushing
> content, and violation of that is a *connection* error.  That doubly
> seems excessive, and I’ll change that in a PR shortly.)