Re: [quicwg/base-drafts] Some correctness issues in the HTTP/3 drafts are stream errors, not connection errors (#2511)

Kazuho Oku <> Sat, 09 March 2019 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8466130EA8 for <>; Sat, 9 Mar 2019 13:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 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_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 YyJSwR5sLYVP for <>; Sat, 9 Mar 2019 13:37:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31431124408 for <>; Sat, 9 Mar 2019 13:37:21 -0800 (PST)
Date: Sat, 09 Mar 2019 13:37:19 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1552167439; bh=rIv5UJKduBKPwPdoS9GN0FT9yftFuFKrCUw9/1AlLFo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uq+PciI/W8aITLuGokg2LX0Dr12z9Dhs2JPRDh5kCq+RuL8HJNkFSs/secveMYH3s LGqXOOfvFpSyvyMsSOtxgBis8yyEz759hG4MoAl1lECR2wEjYux0aovuVgmZU8xYRK iqPiG6QRUGxUtPdK1hp8eNgOitANFlGe0CWZ5nOo=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2511/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Some correctness issues in the HTTP/3 drafts are stream errors, not connection errors (#2511)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c84320fda01a_20df3faf754d45b81576357"; 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: Sat, 09 Mar 2019 21:37:23 -0000

How about "an endpoint encountering a header list larger than the value advertised using SETTINGS_MAX_HEADER_LIST_SIZE parameter MUST close the connection with a connection error."

I do not think we should mandate the use of SETTINGS_MAX_HEADER_LIST_SIZE when imposing a limit on the header list size. This is because the maximum can be different between requests. For a proxy, the maximum size is actually unknown, because each origin would have different maximums.

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