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

ianswett <> Sat, 09 March 2019 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1230126E5C for <>; Sat, 9 Mar 2019 06:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Status: No, score=-8.002 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, 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 5bEvNvZKammh for <>; Sat, 9 Mar 2019 06:17:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DDC31276D0 for <>; Sat, 9 Mar 2019 06:17:59 -0800 (PST)
Date: Sat, 09 Mar 2019 06:17:58 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1552141078; bh=KqTh7nZKifeCRLC2QL76E9TRJmmkWbLgFvmKNL8A4Mc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=X5Dm3y0LAz/Fp8IjS5GblRqAqJaJ2HmfjhGjKiwZsRtrVY3od4VgVUrOkTG76SzyU bJ6xPpXp0rfeX4wYzQ8FNjZFtLQxuOeNVaOIwvSwyqgkqIbqC8NzSdDYzd3ACKRADo vfufvgBSpfAhdzvrelxKyKDR6DYxYTe+hnWfoavU=
From: ianswett <>
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_5c83cb16423c2_23b93fb53ced45b4336123"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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 14:18:01 -0000

The current text is:
"encountering a larger message header SHOULD be treated as a stream error of type "HTTP_EXCESSIVE_LOAD".  If an implementation wishes to advise its peer of this limit, it can be conveyed as a number of bytes in the "SETTINGS_MAX_HEADER_LIST_SIZE" parameter."

To me, the issue here is that a peer can have a limit, but is not required to advertise that limit.  If we required that if a peer has a limit, it must advertise it and enforce it, then closing the connection makes sense to me.

Given it's really easy to advertise it and it's within encryption, I don't see any reason not to make that change, but it's a slightly larger change than the other cases, where we're changing obviously avoidable errors to connection errors.

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