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

Martin Thomson <> Wed, 08 January 2020 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CCE9120018 for <>; Tue, 7 Jan 2020 16:25: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 YkX5h9tOcm1t for <>; Tue, 7 Jan 2020 16:25: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 5151512080E for <>; Tue, 7 Jan 2020 16:25:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ABF551C0DAA for <>; Tue, 7 Jan 2020 16:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578443113; bh=DEzhkQY20HBGLk92YJHEUQi1HCEaKEUFATrepvDbH34=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=nA2mzLFeuuntp7qa5MAocWMLeQWgB6dIJrIvtrg1kr5bf81iwd8sFXtr8ZF8gVPNt w2UjG7JNe1+TZEQWYmZ8VBFZPqFgQ8RZo9eu82al4+wWHb5eVnrioSQUsYBwCcV4rL rvUBOIWLzNbJqJkpJEBwee7s4BiJjvovZe0+ha3U=
Date: Tue, 07 Jan 2020 16:25:13 -0800
From: Martin Thomson <>
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_5e1521699c368_78493fbf47acd960661aa"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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, 08 Jan 2020 00:25:16 -0000

Out of the discussion here only one thing changed my mind: utility.  A client that receives DUPLICATE_PUSH after PUSH_PROMISE receives no new actionable information, so the main question is what happens when DUPLICATE_PUSH precedes PUSH_PROMISE.  In that case, the appearance of a new resource that *might* be pushed creates uncertainty in the client.

The client might hold requests on the basis that something is forthcoming, but they don't know which resource, or even where to block.  If there was a URL, you could answer the what question; if there was a stream ID for the original promise you could answer the where question and maybe block on that stream instead (yay, more cross-stream dependencies!).

But in the end, it seems better to not build the additional complexity.  Allow duplicate PUSH_PROMISES and require that they be sent with the same content, but not require that receivers check (allow them to assume equality).  I don't have an opinion on byte-for-byte equality post-QPACK-decode, but I wouldn't want byte-for-byte equality on the encoded contents as that imposes restrictions on implementations.  If enforcement of equality is discretionary or opportunistic, then we can afford to let the enforcer do a little more work.

The current PR seems about right on all counts.

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