Re: Working Group Last Call: Structured Headers for HTTP

Mark Nottingham <> Tue, 25 February 2020 00:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E1B03A1679 for <>; Mon, 24 Feb 2020 16:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 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.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=ZV1Smnm+; dkim=pass (2048-bit key) header.b=w+2ZMX9i
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nl64qC-T14Nt for <>; Mon, 24 Feb 2020 16:37:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 928F63A1678 for <>; Mon, 24 Feb 2020 16:37:41 -0800 (PST)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1j6OBJ-0006u9-On for; Tue, 25 Feb 2020 00:34:38 +0000
Resent-Date: Tue, 25 Feb 2020 00:34:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j6OBE-0006tI-PV for; Tue, 25 Feb 2020 00:34:32 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j6OBC-0004nF-O9 for; Tue, 25 Feb 2020 00:34:32 +0000
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 3649921EF0; Mon, 24 Feb 2020 19:34:18 -0500 (EST)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Mon, 24 Feb 2020 19:34:18 -0500
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=2 qdP07BLbhObuytUjUZ5CqULo+aDBfSCh+g5MBX12qE=; b=ZV1Smnm+Sn+8cgP/a y8vXlUKtPYMWzngxWN6SPDhB0gJ+RDUE7yRRLRslMFi1iOeU4G3+p269woVB/tBv TdH5GIwgkmkoJ9E/m+cbwZQB1Bf+kWkZuGkiFwQsczJH2omZw7BAcwSJ2FTSTgn4 w3NmHMy3l+22/A/atTL5gntVirvNHoZZi5l1er7o49dGe5dVnwKypxEz47xgwZA0 e3qoPb/ov6AB+NG1WEiLk8vvEQEUfoXPQJR9vRe/X8+kGAKz1B98d1QWdRvZcb/O GmiLg7d9ZLmME0ieLGJA9mf5f+Sm/FbUc9+iQ4jubmHreA94BihcviTzQgFJVHaN rvJtg==
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=2qdP07BLbhObuytUjUZ5CqULo+aDBfSCh+g5MBX12 qE=; b=w+2ZMX9i73Fg3zFlFKtbMwXUzI1s8UYDAT0ck6kP2vc/yTAQjhPrlDmji 4BN9U23jd8B1SqA0YpE5qos+4KhJlZgyUP8PfNfyhtde6MY8ObGvIh+ohagt1ZXA owUpcOOWrWU0eL/+O+4X4LYK3JMpmdyXLv4Hx2dx5fIrwlhPO5nerCmq8BzTssBZ 9qS4TmA7/fbIpVQF1VL95Km+8+AfbHm2ZA14889ZkeYqru2eBeSc6c0CcXQ6mpwx NdMNvGjqM+Zaznms93WZQJJIgKDS/N3UpSuecdnULjo7dUpfs5j2PRKzS++vo7a5 Oq0RYGApctP7RvAMf7ovuBKCRXoLg==
X-ME-Sender: <xms:iWtUXuHjRITcnH5Wn9kFHzrB5WitfICQkdAnCGhGvRyt0-sTuZqV7g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrledugddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hhthhtphhhvggruggvrhhsrghnughtrhgrihhlvghrshdrihhmpdhgihhthhhusgdrtgho mhdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohht rdhnvght
X-ME-Proxy: <xmx:iWtUXmb5DulPWP3XmkT9xSBLl-DbrYf-YRP3YEpzayludxooWggxOw> <xmx:iWtUXgIdr1wMjgpJLgCZq85BnGAnuYe8CpoTURPZqlRSE_XyHjMFPA> <xmx:iWtUXpwy18QwAONbL7G_gXNj5kg-B_8nrDBkXxI61dlM_lyE6754Nw> <xmx:imtUXjRjNim09rR6Q3S1abBJvbH40vxwIDdU-nUlZfEXuWrLirYX4Q>
Received: from (unknown []) by (Postfix) with ESMTPA id 6BC573060FE0; Mon, 24 Feb 2020 19:34:13 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 25 Feb 2020 11:34:10 +1100
Cc: Tommy Pauly <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Julian F. Reschke" <>
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, 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: 1j6OBC-0004nF-O9 bc4c132580ebe1dd75fdffc280351f2e
Subject: Re: Working Group Last Call: Structured Headers for HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/37384
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 24 Feb 2020, at 8:23 pm, Julian Reschke <> wrote:

>>> That said, the title probably should also change from "Structured
>>> Headers for HTTP" to something like "Structured Field Values for HTTP
>>> Headers and Trailers".
>> I'm not against that, although it's quite wordy. Anyone else have thoughts?
> Or just "Structured Field Values for HTTP".

That's better, and I think I can live with it -- as long as we establish that "Structured Headers" is an alias for it (and still use that in-spec, as it's in a number of places). Make sense?

>>> 2. use of "URL" comes as as surprise here, maybe just say "field value"
>> The intent is to ignore the individual URL, not the entire field value.
> Ack. But the mix of "URI-reference" and "URL" is just confusing.

Fixed in

>>> In Section 3.2:
>>>> Members whose value is Boolean true MUST omit that value when serialised, unless it has parameters. For example, here both “b” and “c” are true, but “c”’s value is serialised because it has parameters:
>>>> Example-DictHeader: a=?0, b, c=?1; foo=bar
>>> I guess this is needed in order to avoid ambiguities, but this outcome
>>> is really a bit strange. Is there a summary of how we got to that
>>> special case somewhere (github issue?)
> Hm, that refers to existing field values, which the spec says are out of
> scope.

Yes - but future specs may build upon that capability.

> That said, I *do* agree that the value-less variant is nice for flags;
> my question is why we ended up with special-casing this in parameters,
> and also why we don't allow serialising with "true" value outside
> parameters.

The bug has the history; basically there are a number of already-defined headers that have value-less parameters that previously failed parsing as SH. *If* we want to try to back-port them in the future, accommodating that seems important.

>>> In Section 3.3:
>>>> An item is can be a integer (Section 3.3.1), decimal (Section 3.3.2), string (Section 3.3.3), token (Section 3.3.4), byte sequence (Section 3.3.5), or Boolean (Section 3.3.6).
>>> Please be consistent in upper/lowercasing...
>> Boolean refers to a person's name; lowercasing it would be equivalent to saying that your review is reschkean, not Reschkean. Or are you suggesting we uppercase all of them (which might be reasonable, given the next comment)?
> In that case I'd suggest uppercasing for consistency.

This ended up being more intrusive; once I looked at the whole spec with this in mind, a number of changes were necessary. Please review:

>>> In Section 3.3.2:
>>>> Decimals are numbers with an integer and a fractional component. The Integer component has at most 12 digits; the fractional component has at most three digits.
>>> Same here.
>> Uppercase is used to refer to the SH-type; lowercase is referring to mathematical concepts.
> "Integer component" vs "fractional component".


Thanks again,

Mark Nottingham