Re: [quicwg/base-drafts] HTTP/3 references QUIC Stream IDs directly, allowing illegal references (#3273)

Kazuho Oku <> Mon, 25 November 2019 00:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCE31120132 for <>; Sun, 24 Nov 2019 16:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Status: No, score=-6.597 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 qifgGwsj5akT for <>; Sun, 24 Nov 2019 16:59:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BF9B120125 for <>; Sun, 24 Nov 2019 16:59:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 74831520079 for <>; Sun, 24 Nov 2019 16:59:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1574643582; bh=1Q1y8/dD960n4JkqWFq69LnDdPY0dT4tgCouAb09OVk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rDW9k/u0y/P8cfzR5UzWDYTn2uIK5jEgs0MyT7VkXWpgMhvIPf08f3D6ULmgoziJk 3N2mHlrnY54NkKmrZMZlueE52gdee5+5yZFpgMrh/boQ1ZjfF5PsuVMGtisoItRb7T cBpabPr4Fdy9TCGUXe6hyMlhmesQkIMmvCY4Xzuc=
Date: Sun, 24 Nov 2019 16:59:42 -0800
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3273/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] HTTP/3 references QUIC Stream IDs directly, allowing illegal references (#3273)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ddb277e650ed_9e33fb7698cd95c106618c"; 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: Mon, 25 Nov 2019 00:59:45 -0000

While I agree that such a design is possible, I am in favor of using stream IDs as they are, because that is what we have done in HTTP/2.

To be precise, HTTP/2 has stream 0 (which is used for transmitting control messages), odd-numbered streams (for carrying requests), even-numbered streams (for carrying pushed requests).

To paraphrase, we have had these ID holes in HTTP/2, and we haven't had issues (I assume). We've already built our infrastructure around this design, for example, we simply log the stream ID and hope that that would be sufficient to identify the request, regardless of it being one initiated by the client or one being pushed by the server.

Introducing the concept of "request ID" would be a departure from this design in HTTP/2. As there would be a different number space for pushed requests, we'd be required to change the logging structure to convey a tuple of request-type and request-ID. While that is not impossible, I am not sure if that change is worth the cost.

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