Re: Magnus Westerlund's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)

Mark Nottingham <> Thu, 21 May 2020 03:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90E323A0A43 for <>; Wed, 20 May 2020 20:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=JrwsIoLn; dkim=pass (2048-bit key) header.b=xukncDj0
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vxC9v75u4AYf for <>; Wed, 20 May 2020 20:32:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACC0A3A0A3E for <>; Wed, 20 May 2020 20:32:55 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jbbuF-0003Mu-Nn for; Thu, 21 May 2020 03:30:03 +0000
Resent-Date: Thu, 21 May 2020 03:30:03 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbbuE-0003M3-Go for; Thu, 21 May 2020 03:30:02 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbbuC-0002lG-CT for; Thu, 21 May 2020 03:30:02 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 7835C5C010A; Wed, 20 May 2020 23:29:47 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Wed, 20 May 2020 23:29:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=7 i4zEjbKBKUmM2n6pRCt6YzN+bsTbJEmkluV/PrYdxw=; b=JrwsIoLnis7Pqq50J jag/C5anQ0pedLce91xblPMhdvh56MuKfMT+k3bwODbxnan7T0LXK8guRxvXvmlj QAuGTfoqHBRZ4JNQ0a2ra9i2/5BcPTiVVJZtjBaFEI3WWlFELUO2859NmvATVprC 5kJGxQIsTgIwPTnFERBhmW3Oz+GBLqYfqjvLn5X8yIGWSI+P80w5YbtVB1Ll37MN cmB59IwGieS++j+7iQVkSK+bSBMqcT+UxUoOkEHSIduplkDE1M/ZhiFo4Q9IAGGj NA/XxhMGyyGWTZujyFtBEQOFpXOrOQ/szSkTkUeqcCYEtJpkt8CiUQKsXrNUEu1d ct93g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=7i4zEjbKBKUmM2n6pRCt6YzN+bsTbJEmkluV/PrYd xw=; b=xukncDj0wyTOd9/jGAQwWgp/dqVDQdVPI8I/0OMlLeE8TiiWmzpONI9H8 qNeBIkAb0rPgP61hdjMrAKLEnM4qvcswxO8D8TRcMhTd61g2ipSkQRTdznrYdDDh 3m6E8Kj0O2tawouFy+qjsUHhozDyB9mcQoAbpEgBhJV3Kd2bjVK57RvWRz18oS/D 2EPQ7ozKWA/sIPaaKI+xz8S4RthMJQSEPKmqgsCrtQyV7B0Jwz3iPVJwoBopcAwE Qaupkku3pzmkTibOgNUnuFlJueGQqTnXaf+bbFmqeQKfv8ORlWeqanEoUUH6QJy1 FbWbZXR+sRsxrEY81Haq0aN9MtBMA==
X-ME-Sender: <xms:qvXFXvK6olDnbWqxuu3eYPxj5wF-22divhPmps1_axN-iGdTSbvUAQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddutddgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeegjeeuuddukedtgfetiedvfeeuhfejtddvgfeuleeikedvgeetteetgeffiedt teenucffohhmrghinhephhhtthhphhgvrgguvghrfhhivghluggtohhnvhgvhihsihhnfh horhhmrghtihhonhgrsghouhhthhhofihmuhgthhhfohhothhhvghmvghsshgrghgvhhgr shdrfhhoohdpvgigrghmphhlvgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeduudelrd dujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:qvXFXjIhTQTOBZTnxhe6-aq9_sVzBVxPnChFoiPVSMHYKRop8rKf3w> <xmx:qvXFXntmIg5TBEifbTqJr3jZhdltGtY9NOj-b2j5es6UWP0l7KEgUA> <xmx:qvXFXoaQ_1RiskgsWhNCPh2NwUoqnJEDO8mpGZAyDVqkXepQttOu8g> <xmx:q_XFXtz6PtGFhSf5QKwudl-Wx1Z0Sq1LPMVrd38OF_OgkAJcs9_1zw>
Received: from ( []) by (Postfix) with ESMTPA id 0A7DD3280059; Wed, 20 May 2020 23:29:43 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 21 May 2020 13:29:41 +1000
Cc: The IESG <>,,,, Tommy Pauly <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Magnus Westerlund <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jbbuC-0002lG-CT c8299991475176a70156541497368e7c
Subject: Re: Magnus Westerlund's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37694
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Magnus,

Thanks for the review. Responses below.

> On 21 May 2020, at 2:14 am, Magnus Westerlund via Datatracker <> wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> A. Section 3.1:
>   The ABNF for Lists in HTTP fields is:
>   sh-list       = list-member *( *SP "," *SP list-member )
>   list-member   = sh-item / inner-list
>   Each member is separated by a comma and optional whitespace.
> To me there is a clarity issue that could lead to interoperability issues.
> Namely the difference in the meaning of whitespace between RFC 7230 and this
> document. Structured headers appear to not allow the HTAB that RFC7230 allows.
> And that is fine, but I would expect this to be more clearly discussed. If the
> intention was to allow for HTAB you need to use WSP rather than SP in above
> rule.

Hm. Conceivably, someone (e.g., an intermediary or a library) could combine two header instances and use COMMA HTAB; while the current text in 7230 only says "separated by a comma", but the (I believe more correct) text in semantics-core says "separated by a comma and optional whitespace. For consistency, use comma SP."

I think the chances of that actually being a problem are very, very small; by far the most common practice is comma SP. However, it's hard to rule out completely.

At this late stage, this is a non-trivial change; the risk of an implementation not updating for it is relatively low, but the risk of getting the fix wrong is much higher. So, I'm going to prepare a pull request and circulate it in the community to both get more eyes on it, and make sure the change gets consensus.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 1. Section 2, page 8:
>   --8<--
>     42. Foo-Example Header
>   The Foo-Example HTTP header field conveys information about how
>   much Foo the message has.
>   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
>   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:
>     Foo-Example = sh-integer
>   Its value indicates the amount of Foo in the message, and MUST
>   be between 0 and 10, inclusive; other values MUST cause
>   the entire header field to be ignored.
>   The following parameters are defined:
>   * A Parameter whose name is "foourl", and whose value is a String
>     (Section Y.Y of [RFCxxxx]), conveying the Foo URL
>     for the message. See below for processing requirements.
>   "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
>   its value is not a valid URI-reference, the entire header field
>   MUST be ignored. If its value is a relative reference (Section 4.2
>   of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before
>   being used.
>   For example:
>     Foo-Example: 2; foourl=""
>   --8<--
> To me this example indicates several unclarities in this specification.
> First there is a lack of discussion of the definition of the field-name and
> clearly identify it. In the above example it is only implicit identified. I
> would propose that this example has an additional paragraph that explicitly
> defined the Structure header name as discussed in the paragraph above this
> example.
> Per RFC 7230 Section 3.2 a header field is the complete structure of field-name
> ":" OWS field-value OWS. However looking at this example it appears that
> structured header field only define the field-value. Wouldn't it be better to
> be explicit about these two components although I understand that field-name is
> a constant. This is also evident in what appears to be a grammatical error in
> the above paragraph:

This is how we define HTTP headers; see for example the core documents, RFC7230, or most any of the extensions we're working on. There's been a lot of discussion leading up to this, and I won't reiterate all of that here; but it's pretty settled.

>   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
>   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:
> The second "Its" would to me indicate Foo-Example a Item Structured Header, not
> the header value (field-value in ABNF) which is defined. I would suggest
> changing the second Its to "The Structured header value ABNF is:"

I don't think that's an improvement.


Mark Nottingham