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

Mike Bishop <> Mon, 16 December 2019 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6DCA1201DE for <>; Mon, 16 Dec 2019 08:34:07 -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 wRxLJ-FhYdGn for <>; Mon, 16 Dec 2019 08:34:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 837F21200D8 for <>; Mon, 16 Dec 2019 08:34:05 -0800 (PST)
Date: Mon, 16 Dec 2019 08:34:04 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576514045; bh=Kg97ddNdAHqmI/xncXGvdw4KAJHbOTAATyP9rbwG/tk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZGAl36SD+eNIDvCKU6kLufCbsIku+HuQD6DtZoe4BuS90djn/Md1jOe/dSbd3jUBP Z1w6mzY9FhJszxa5/B9lferQMh4Y4MT9LIAVBHcaybYbfTFjF1qCHInkOAv+fnAnRd 3+dLg5tmSzX2VhtgM3e3gVyxJjJPE48D5nHcrrCM=
From: Mike Bishop <>
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_5df7b1fcc31be_4c453fd1812cd96c229617"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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: Mon, 16 Dec 2019 16:34:08 -0000

> Nevertheless, the current design must have some rationale behind it, which I expect @MikeBishop to share with us on this thread.

I think I've been adequately channeled in the meantime.  😉

As others have pointed out, this was a compromise that no one was thrilled about, but was considered better than the status quo and no ingenious solution to all issues has yet presented itself.  The solution space that I see is:

- **One request, one promise, one push.**  H2-style, every push is promised to one and only one request.
- **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:
  - **Allowed to differ**; each promise separately contains the headers of the request, and if different requests would have garnered identical responses, this is fine.  (For example, pushing "empty list" for lots of subresources the client might have wanted to retrieve as part of an API.)
  - **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?
- **Headers sent once; DUPLICATE_PUSH frame.**  This is the compromise we landed on.  It's true that this means the headers might not be available at the point DUPLICATE_PUSH is received.
- **Headers sent once on push stream; DUPLICATE_PUSH becomes PUSH_PROMISE.**  Conceptually easier, but means headers are almost certainly not available at the point the promise is received.  Means promised request can't be delivered without enough stream credit to do the push itself.

The idea of including a URI in DUPLICATE_PUSH is an interesting one, and might reduce the amount of blocking clients need to do until the push request is received.  It also makes that last solution more palatable.  Presumably, if the server is pushing a request for a URI, the odds that the request will match what the client would have sent better be high.

I don't personally believe this change is warranted in late stage, but I'm willing to take an improvement the working group reaches consensus on.

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