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

Kazuho Oku <> Tue, 03 December 2019 06:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAD631200C5 for <>; Mon, 2 Dec 2019 22:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, 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 SvpXgta3LNJK for <>; Mon, 2 Dec 2019 22:15:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50915120033 for <>; Mon, 2 Dec 2019 22:15:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4862F9604D9 for <>; Mon, 2 Dec 2019 22:15:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1575353717; bh=s5WzFhx8mMubeVsKFxaWFZZaPKw2MeRTt5Rquh1Fo0k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=z/6aX0UwDrCyRq2YrMNKKqInE9XkTRVpt18Bxs5VXnaYryc5b9OzHrnPT2gmmap9N XgPRYdo0j4k4vAn7+gsWEpJiXuhhD9VdGaAwoWq6HFn/3LgrjzlJfUFVdeA8DPldlP WSWX2E2JPdgQS+DvMuGxmec3jrh1K+n7sX5Jdhk4=
Date: Mon, 02 Dec 2019 22:15:17 -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_5de5fd7538425_66473fef782cd95c68338"; 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: Tue, 03 Dec 2019 06:15:20 -0000

@RyanAtGoogle I kind of agree, and kind of disagree.

> * HTTP/3 server push works incredibly differently than HTTP/2

I am not sure how different they are. As you correctly point out, the benefit you achieve by pushing is limited to one BDP in HTTP/2. As there is the potential of pushing a response that has already been cached by the client, pushing too much has been a bad idea in HTTP/2. IMO, the fact that we are additionally capped by the push stream concurrency in HTTP/3 does not change the big picture.

> * At a minimum we should probably provide advice about how the client should manage MAX_STREAMS and MAX_PUSH_ID


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

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