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

Dmitri Tikhonov <> Wed, 27 November 2019 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36D09120123 for <>; Wed, 27 Nov 2019 05:54:41 -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 RZOMhCju5Q0p for <>; Wed, 27 Nov 2019 05:54:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C72E120122 for <>; Wed, 27 Nov 2019 05:54:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B89FD961A64 for <>; Wed, 27 Nov 2019 05:54:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1574862878; bh=6NIC8aclJBF3lOrYBth/l0tN9AfGddUTRcPtqIVh97s=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=szGnNBmS5XcIEKEGYhtUnMAoAq9YFDdQwb86weQxzy0KAAciokPxLu003fYFNEVWK YHxez8+aFQXt56Srsg2GWz4fzNoAJsqY9WBit22y/ZquXUgsAfkvN73QaSUaK3QCBS 5474U7hDRxZjGQBVJOlHvY612rSkPPhqGvNq4/ro=
Date: Wed, 27 Nov 2019 05:54:38 -0800
From: Dmitri Tikhonov <>
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_5dde801ea8fe1_67ad3f837b6cd96c3660aa"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: dtikhonov
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, 27 Nov 2019 13:54:41 -0000

Having implemented DUPLICATE_PUSH on the server, I say that the complexity is increased compared with gQUIC or HTTP/2, but it's not too bad.

On the client side, the biggest problem I haven't yet solved is that push promise, when received, might not have a stream associated with it.  At that point, the user code cannot be given a push promise stream to process or refuse the push promise.  This can be solved in a few ways:
- delay informing the user that push promise has arrived until the push stream gets created;
- create a stream but delay assigning stream ID to it (and disable some stream functionality); or
- create a different API for HTTP/3 push promises.

I haven't made up my mind about which of these I dislike the least.

@kazuho's proposal would solve this problem on the client and so I agree with his argumentation regarding client complexity.  Nevertheless, the current design must have some rationale behind it, which I expect @MikeBishop to share with us on this thread.

We should also keep in mind that the HTTP draft entered Late Stage yesterday.

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