Re: [quicwg/base-drafts] all HTTP/3 protocol violations should lead to connection errors (#2510)

Kazuho Oku <> Mon, 11 March 2019 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DCEB12796B for <>; Mon, 11 Mar 2019 13:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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_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 V163huBaAE24 for <>; Mon, 11 Mar 2019 13:16:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C08C7131151 for <>; Mon, 11 Mar 2019 13:16:20 -0700 (PDT)
Date: Mon, 11 Mar 2019 13:16:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1552335379; bh=SkjLqPVQaAez0fmlYwDaaoVB5VDbVlWsjlEEDT9fuQs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Zus8EFo/lT/1Mcon66LbpG0F8Evpk+RHPcvINlS3A2dIze5GFCzPJ3YbLkSe9Xcp8 LF5tw5REIOgTNFRr53pAnYY+eKsJNcse1OJSRi57NctmBGox1Y0MKmSPzR2qfxgvnP F093BkNW1RVC/llBd35WPpVSf53pFfU2IKzC9WoY=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2510/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] all HTTP/3 protocol violations should lead to connection errors (#2510)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c86c2133b4bf_1e353f9753cd45b8470b8"; 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, 11 Mar 2019 20:16:33 -0000

>> An endpoint MUST NOT send a header list that exceeds the peer-advised limit.
> How can this be justified? This is a departure from RFC 7540, which states in two places that this setting is only advisory.

Yeah. My read of HTTP/3 is that it is already different from HTTP/2 this respect. It is no more clarifies as "advisory," no there is a mention that a client can exceed the limit (a text that exists in RFC 7540).

Regarding the ideal behavior, I prefer being strict here, because it would give us the most predictive behavior at a minimal cost (it's trivial to check the size, isn't it?). Think it from an end-user perspective. Without the restriction, we might see one user-agent telling you that the request is too large, and the other processing the same request. That'd be confusing.

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