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

Kazuho Oku <> Tue, 17 December 2019 04:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F48C1200A3 for <>; Mon, 16 Dec 2019 20:53:16 -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 NnRo4NwdN7f9 for <>; Mon, 16 Dec 2019 20:53:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3A6F120098 for <>; Mon, 16 Dec 2019 20:53:13 -0800 (PST)
Date: Mon, 16 Dec 2019 20:53:13 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576558393; bh=6MRJn88iVXiMaIOorVUS6J8fIJvYWKwlv09G13wyeUs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DWWCNwRG14nPFOoKJg62WM3y2GCINz/ViysLM6s2xo0XkLJXAsi0Ftcwh3TDPPE2y r5S+SitCAsFoc2ARucmlqx5Kq71YLTKHgilqvl9BmVlCMO1/9M7fmgK5I79OTYjEmG bE65Hcm9iTFJp/VAQavRyAHqzN9rFLwSGTPhnLDQ=
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_5df85f392662b_76b33fe3d06cd95c3301aa"; 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, 17 Dec 2019 04:53:16 -0000

@MikeBishop Thank you for laying down the options.

My preference goes to:

> * **Multiple PUSH_PROMISE frames on different streams.** Old H3-style; wastes some bytes repeating yourself, and now we have to talk about consistency between them:
>   * **Not allowed to differ**; client has to check that the headers are the same. What if they're not? How long does the client have to keep the headers? Need it be the same bytes, or simply the same resulting header set?

Regarding the points listed as questions, I think we should state that the header set that the server sends MUST contain the exact same bytes (after decompression), and that a client MUST either validate that they are the same, or ignore the PUSH_PROMISE.

By using MAX_PUSH_ID frame, the client controls the number of pushes that the server can initiate. It can track the unused push IDs much like the QUIC transport tracks unused stream IDs. By tracking that, the client can tell if a PUSH_PROMISE frame contains a new push or if is a duplicate. If it is a duplicate that it has already forgotten, then it can simply ignore it.

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