Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)

Lucas Pardue <> Wed, 07 August 2019 13:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0797512015F for <>; Wed, 7 Aug 2019 06:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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 26swzQ-n-_on for <>; Wed, 7 Aug 2019 06:16:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 146BB12004C for <>; Wed, 7 Aug 2019 06:16:35 -0700 (PDT)
Date: Wed, 07 Aug 2019 06:16:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1565183794; bh=kJ2chK7Cr/nxQmTMjxbH6JW8AOGWBmF3bQ8iOdlFdEQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WS7BqjcWBiEy07CesRH7KQa4YpsrVh0WiS5NVBjPNGTc+6+P9xsAOeH82JJ0nTU7w q8mSFYg5nw+wbB+HX2ierTpDL9qTa5/fH60QLy+M+LNEVQCbV7bzfLsL4Q7iapC5jh m9g2oe+7cD0ro/ghNwH5+Y8yb0OtxLKoBFlhU1Sc=
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2945/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d4acf3293e_24fa3fe73cacd95c383752"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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: Wed, 07 Aug 2019 13:16:37 -0000

Yes it would be unwise because there's a good enough fall back, use static compression.

Pending priority removal from the spec, the only thing SETTINGS holds is header-related parameters. Removing the QPACK dynamic table aspect from the discussion means that we are discussing only SETTINGS_MAX_HEADER_LIST_SIZE. We discussed the usefulness of that parameter on #2516, with some happy to support its removal; but we decided in London to keep it.

So all we can talk about for SETTINGS is in terms of extensions, known or unknown. Sending SETTINGS isn't blocked on the peer but is that true for how an application acts upon those SETTINGS? E.g. Should a server that implements an extension and advertises it in its SETTINGS block until it receives a SETTINGS from its peer? That depends on the nature of the extension. 

So on this axiom, I'd be happy with text that says an endpoint MUST send SETTINGS before all other activity, along with some guidance in the "Extension to HTTP/3" section that describes the risks in blocking on reception of SETTINGS.

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