Re: [quicwg/base-drafts] Semantics of SETTINGS_MAX_HEADER_LIST_SIZE (#2516)

Mike Bishop <notifications@github.com> Wed, 24 April 2019 22:48 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7531200FC for <quic-issues@ietfa.amsl.com>; Wed, 24 Apr 2019 15:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRlI36y13Oa0 for <quic-issues@ietfa.amsl.com>; Wed, 24 Apr 2019 15:48:14 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFFE12044B for <quic-issues@ietf.org>; Wed, 24 Apr 2019 15:48:14 -0700 (PDT)
Date: Wed, 24 Apr 2019 15:48:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1556146093; bh=HrREsF532zfky3j7+qo6j4xMTwzosuQtu9k1sWiCtVg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=acO9MCY9JLBqX0lnyszSkvDL6kvrJVr0tQoepAuc7wr5hVJU48nkLG1pEEDmOL4Yk FrDAVYAr2wRDArkQPTkzV9VW1uI/Zx4/Yg/BCv1Nolm4opWY/Ji8lJ4zocQHXKrTeX WNKbuNYMoQty32p+Sn5C6y4FTAR/UuBB9iULHbLM=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2DKR7AKX5LYKCYSP52ZYNC3EVBNHHBSBBRWE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2516/486456057@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2516@github.com>
References: <quicwg/base-drafts/issues/2516@github.com>
Subject: Re: [quicwg/base-drafts] Semantics of SETTINGS_MAX_HEADER_LIST_SIZE (#2516)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc0e7ad909e1_2d773fc2650cd96c775ab"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/oYxvY-MvJdh7V6CFdRaERW8BwJU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2019 22:48:17 -0000

In theory, this should advertise the limit beyond which a peer wouldn't have propagated the payload anyway; it permits, but doesn't require, the entity that's about to send the payload to send a (miniscule) error in the opposite direction / on the API rather than forwarding a message it expects to be rejected based on header size.  That's purely an optimization, and it's always acceptable to just transfer the big thing and find out at the end that it failed.

Because there could be multiple intermediaries, it's entirely possible that one stream could see an EXCESSIVE_LOAD error even though the headers weren't too large for the first hop upstream.  That's one of the biggest reasons this needs to be a stream error -- the setting is hop-by-hop, but enforcement is ultimately on a per-request basis across the set of hops.

If used this way, it shouldn't break anything that wasn't broken before -- things that would have failed will simply fail faster.  If you don't implement it, then you'll still eventually get an EXCESSIVE_LOAD or a 400.

I agree that the current text doesn't reflect this usage pattern.  If we agree that this is the correct way to envision it, I'll write up better text.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2516#issuecomment-486456057