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

Martin Thomson <> Wed, 04 December 2019 03:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9121C1200B4 for <>; Tue, 3 Dec 2019 19:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.072
X-Spam-Status: No, score=-8.072 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, RCVD_IN_MSPIKE_H2=-0.073, 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 AgUnVj-TF9tA for <>; Tue, 3 Dec 2019 19:17:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C10431200A4 for <>; Tue, 3 Dec 2019 19:17:53 -0800 (PST)
Date: Tue, 03 Dec 2019 19:17:53 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1575429473; bh=C2yimaA9COuEWlTS6L7yLA4jPz6dDwZ0m8F6BLYJBqo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eBM2DQfwn1WjQH7FxCBqfxVPkvVb9GaclUkHymMjzb6pw8oEUB+A0i1Qzw7MB+Tmi gMyk3r0E2aoMxxdDjThey6vpL23gKRog7H16bSgFYnjaGRHwjRkrUPlXiQnmfonxNB Zkdohik0wOCpkkdHZ+fUwIBl6NQVxJwngn4fztYY=
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_5de72561102be_55483f7fd68cd96822944d"; 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, 04 Dec 2019 03:17:55 -0000

Unlimited pushes in HTTP/2 was a bug, not a feature.  The concurrency limit might have applied in theory, but the ability to run the entire stream lifecycle without feedback meant that there was no limit in practice other than those imposed by TCP - on either promises or responses.

The important feature, which we retained, was the ability to decouple the stream limits and the number of promises.  That's why we have push IDs.  Assuming the client is configured for that, the separate limit on push promises ensures that promises can greatly exceed the number of active streams.  I think that is the ideal situation if the client is somehow resource-limited, so it can accept N promises and then receive M (<N) responses for those promises.

In other words, I see no reason to change the current design.  If this is the result of general antipathy toward server push, that's fine, but we're not in a stage of development where we can afford to make changes at such a fundamental level without serious impact on our schedule.  Besides, I'm not seeing a proposal here that would be anything less than a regression in some way.

If someone wants to contribute text that walks through some of the trade-offs inherent in setting different limits (whether that be streams, flow control, or push IDs) for people who might want to implement or deploy HTTP, that seems fine.  As this is highly context-dependent, it might be hard to avoid certain biases.  I certainly wouldn't want to block publication if such guidance were absent.

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