Re: [quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)

Kazuho Oku <> Wed, 04 December 2019 02:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 731FE120059 for <>; Tue, 3 Dec 2019 18:36:06 -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 McbXj5GW8LmF for <>; Tue, 3 Dec 2019 18:36:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 849BB12001A for <>; Tue, 3 Dec 2019 18:36:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5012D960804 for <>; Tue, 3 Dec 2019 18:36:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1575426962; bh=VTL+jrlLu+s7rg3JcbKI8oS472Cs3a+XO5lGZd0BBec=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Cfkaqx4w3PQFom5G63KWIbsj+rgSbzymBS8c7nSK5ShFGxiIx+MDtYJrexdufnEU1 KY9OYwgL3WFR0F1PRRqs9NmYlPlKYQreZG/7kpuHiweltywl0LAiyPHe8wB4DpFSf2 vbgbKnRFobf5e0PzQ1rJD2fT2sXJlQzvd+QodCdU=
Date: Tue, 03 Dec 2019 18:36:02 -0800
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3275/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5de71b9241b91_6eb83f8c788cd964215878"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Wed, 04 Dec 2019 02:36:06 -0000

I tend to agree with what @RyanAtGoogle says.

IIUC, one of the reasons we have push ID in addition to stream IDs is to limit the exposure of transport features to the application protocol. However, as @ianswett points out in #3273, there is already a leak in the abstraction.

Therefore, I think we can (and should) directly use stream IDs. Doing so would resolve the concern that the push might get blocked by stream concurrency.

>>> * I could almost imagine replacing PUSH_PROMISE completely by a BLOCK_UNTIL_PUSH_RECEIVED frame which specifies a QUIC stream ID and prevents the app from processing the rest of the body until the specified push stream's initial headers are received.
>> I presume that's the same as what I originally proposed in this issue? Personally, I think I am fine with either ways. What I'm unhappy with status-quo is that there is two ways of doing one thing, which is causing complexity.>
> I think this could be what you proposed initially, though I have one point of clarification. I understood the DUPLICATE_PUSH semantics to be that the client would continue to process the body of the stream on which the DUPLICATE_PUSH was sent, but that any requests would be blocked until the associated PUSH_PROMISE was received. I don't like this idea because it blocks all requests, not just those which the server intended to promise. Instead, I'd propose that the frame (whatever we call it) blocks the processing of the stream on which the frame was sent, which prevents the client from discovering the link to the promised resource until the push headers have arrived. (Of course the server should send the push headers on the push stream before it sends the frame on the original stream thus typically the push headers will arrive before the frame).
> Is this latter behavior what you were thinking?

To me, those two approaches sounds like something that a client can choose from, though I agree that the latter is better as it introduces less blocking. If the HTTP/3 draft is not already clear about the intention, it might be a good idea to open an editorial issue, because IMO that is a problem with the DUPLICATE_PUSH frame that already exists.

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