Re: [quicwg/base-drafts] Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3309)

Mike Bishop <> Fri, 10 January 2020 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D961A1200CC for <>; Fri, 10 Jan 2020 13:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3ELCpxwZkqcN for <>; Fri, 10 Jan 2020 13:28:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E553F12008C for <>; Fri, 10 Jan 2020 13:28:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1A7D22C13A7 for <>; Fri, 10 Jan 2020 13:28:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578691721; bh=Cy063o9TheVffw52V5o6UJgcshs4nQdEgmGoioXZCZo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EZMLmaJ/g7uqRh6VZuTwIXKA2+FDdh89TD2gNZeqafmTU2so7wO06Fpvf400vzxfk /bBGRdubc9ANNlYQVsdMNx64wAI8DvfBruw1wisoflAVHRVrO5AncP0xpFHa9+F2/1 YhOX/z2VDv1+cRn3Cr1TRFVZCX/+P1/gfxTax6RA=
Date: Fri, 10 Jan 2020 13:28:41 -0800
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3309/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3309)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e18ec89ab99_49773f98304cd96853189"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jan 2020 21:28:44 -0000

MikeBishop commented on this pull request.

> @@ -1238,9 +1232,20 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a
 PUSH_PROMISE frame that contains a larger Push ID than the client has advertised
 as a connection error of H3_ID_ERROR.
-A server MUST NOT use the same Push ID in multiple PUSH_PROMISE frames. A client
-MUST treat receipt of a Push ID which has already been promised as a connection
-error of type H3_ID_ERROR.
+A server MAY use the same Push ID in multiple PUSH_PROMISE frames. If so, the
+decompressed request header sets MUST contain the same fields in the same
+order, and both the name and and value in each field MUST be exact
+matches. If a client receives a Push ID that has already been promised
+and detects a mismatch, it MUST respond with a connection error of type
+H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the
+client MUST ignore the duplicate PUSH_PROMISE frame.

Yes, I think we've found a conceptual difference.  You're looking at the promise purely as a way to forestall requests for that resource, and the fact that it happens to be on a given stream is only because the server thinks there might be something on that stream where you need to know about the push first.  But handling of push in Chrome is global -- if you request A and B, I promise X on A, and B references X, you'll use the pushed object if you know about it.  I agree, in this implementation style, the first PUSH_PROMISE frame to arrive carries all the information you need, and any subsequent ones are basically irrelevant.

But RFC7540 says that "Pushed responses are always associated with an explicit request from the client."  How (or whether, obviously!) that association is used is implementation-dependent, but I think for consistency's sake we need to provide that association in the document.  (As far as I know, the only thing H2 explicitly used this association for internally was for prioritization -- pushed streams depend on the associated stream.)

Do we need a separate editorial issue to expand on this a bit in the document, or is it there and we're just reading through different filters?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: