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

Mike Bishop <> Fri, 10 January 2020 20:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DE3F120116 for <>; Fri, 10 Jan 2020 12:42:41 -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 lJrfhkXTF53S for <>; Fri, 10 Jan 2020 12:42:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42C16120111 for <>; Fri, 10 Jan 2020 12:42:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4E09C521DB1 for <>; Fri, 10 Jan 2020 12:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578688957; bh=Q6noi0x0N50MuQvZAPfMFJpCMIj/zHhQrXJelN1Uiz4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=M/2OlP0I8GMrb9ZyXe4IKJMHPbML68QsZ4t4QEiUNzV/Fp26BNM6HAp9SLhEKiYF2 WC/THEMd1sprKQfnQUdxZ7AXcWoHHSg5yaVrIaV074t8U4jeQjnTJmccM0F6Rc4SvI eOhNTHUoOEh7XMUYqLKzzqmQo3udWfPmD7KZxCbE=
Date: Fri, 10 Jan 2020 12:42:37 -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_5e18e1bd3fddc_37a93ffd60acd96888994"; 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 20:42:42 -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.

HTTP/2 associates each push with the (single) request where the server promised it.  HTTP/3 allows a push to be associated with multiple requests.

> There is only going to be a single push stream with the specified push id, of course. **And as such, only a single request can be directly associated with that push stream.**

This is the difference -- one need not follow from the other.  HTTP/3 allows a response to be promised on multiple streams, implying that you'll potentially want it as a dependency for each of those things.  That means it's intended to be possible for that push to satisfy several client requests (from different tabs, or threads, or iframes, or whatever).

Now, if the response is cacheable, you're right -- the HTTP cache will probably satisfy those other requests and it doesn't have to reach the push cache.  But the pushed response need not be cacheable; it can nonetheless be used multiple times if promised multiple times.

In WinInet, we had a concept of a navigation that was passed down from the browser, and the push cache was at the navigation level rather than the connection level.  It was part of whichever navigation included the stream that received the promise.  Hypothetically, if something were promised on several streams from different navigations, HTTP/3 would enable putting that response in both navigations' push caches.

Since Chrome can split navigations across connections, doesn't having the push cache at the connection level means you might miss that something was already pushed because it was promised on a different connection than Chrome was going to use for the request?

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