Re: [quicwg/base-drafts] Prohibiting server-initiated streams for h3 (#2711)

Kazuho Oku <> Fri, 17 May 2019 01:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2BAA120334 for <>; Thu, 16 May 2019 18:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 3nAasyIvZ5Pk for <>; Thu, 16 May 2019 18:30:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B986C12002F for <>; Thu, 16 May 2019 18:30:14 -0700 (PDT)
Date: Thu, 16 May 2019 18:30:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1558056613; bh=OIkQlYb86dj+reIVK4aaISstsEe09USQ2tWwRWjz38s=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JApqQA+iHgsqCS43fLIPBh1GBzT9L6KWfojS5nK40IRXhKfw3eIokxJ08QHgp2y6f rq1CmUeloIAVHT2lLAnaTADaTzykHZhdv/z76X7xdeZrFW53IrZdpZd5O8l+W0QPew 8XEKobxktd39k9VqgU465gdp0fO1B5hZhWs0126g=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2711/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Prohibiting server-initiated streams for h3 (#2711)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cde0ea592f36_7cb63fc7082cd9682132f7"; 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: Fri, 17 May 2019 01:30:17 -0000

This might be a transport question, but how should a client respond to a server trying to open a server-initiated bidirectional stream?

Assuming that the client's initial_max_streams_uni is zero, a server would send a STREAMS_BLOCKED frame. In response, the client would send a MAX_STREAMS frame with the value set to zero. However, IIUC, this MAX_STREAMS frame merely indicates that the resource is temporary unavailable. That means that the server would be blocked.

To rephrase, the transport does not provide a way for an endpoint to reject a stream, without letting the peer to actually send a STREAM frame. Are we fine with that?

If we think it as a problem, maybe we should change the definition of initial_max_streams TP. For example, we could specify that the omission of the initial_max_streams TP indicates rejection of the corresponding type of streams being opened (instead of interpreting the omission as "zero").

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