[quicwg/base-drafts] Why is SETTINGS parameter duplication a connection error? (#2663)

Lucas Pardue <notifications@github.com> Wed, 01 May 2019 13:39 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 46BFF1200B2 for <quic-issues@ietfa.amsl.com>; Wed, 1 May 2019 06:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yBQNMBP_gV51 for <quic-issues@ietfa.amsl.com>; Wed, 1 May 2019 06:39:01 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780FD120045 for <quic-issues@ietf.org>; Wed, 1 May 2019 06:39:01 -0700 (PDT)
Date: Wed, 01 May 2019 06:39:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1556717940; bh=swErj7yEBD18V5Chv9DmSPqWdhn9r0pSMyY4YtOD+ok=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=VgFgGKHOx8XVBhBc4CwnPlbRekfMEc4o4WJepjjFmKMs7HqG+8iiNhCtEJZDyIO8b 9gAa8sYu7x9Vj+ZKR5mPJqYIM81QZ91KsoTSFj2F/QeOXQHEyBbAnYRQm9NyZcMyYx zvppx9n4lHNcVT5uce9C1owVmfYEJWQtmBLsv2ug=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY33VFIM2F2ISUIS7F223J7JEVBNHHBULJJJA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2663@github.com>
Subject: [quicwg/base-drafts] Why is SETTINGS parameter duplication a connection error? (#2663)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc9a1746af23_3df23f8043acd96c1176d4"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/zxtcLdZYyh8Cqu1JZF9qeWsq0ao>
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, 01 May 2019 13:39:03 -0000

In draft 01 it was ok to send duplicate parameters in the same frame, in draft 02 several changes were introduced to settings and the changelog links to #181. However, most of the discussion there was about putting SETTINGS in QUIC TP, so it isn't clear why duplication is so problematic.

The old 01 text made sense:

   Each parameter in a SETTINGS frame replaces any existing value for
   that parameter.  Parameters are processed in the order in which they
   appear, and a receiver of a SETTINGS frame does not need to maintain
   any state other than the current value of its parameters.  Therefore,
   the value of a SETTINGS parameter is the last value that is seen by a

These days the draft says:

   Parameters MUST NOT occur more than once in the SETTINGS frame.  A
   receiver MAY treat the presence of the same parameter more than once
   as a connection error of type HTTP_MALFORMED_FRAME.

This adds work on the receiver to maintain state while parsing the SETTINGS frame in order to detect duplication, which is kind of annoying when we consider that the contents of unknown SETTINGS identifiers should be ignored.

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