Re: Working Group Last Call: Structured Headers for HTTP

Julian Reschke <> Sat, 22 February 2020 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3CC13A0799 for <>; Sat, 22 Feb 2020 10:10:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JknSpxokHmLS for <>; Sat, 22 Feb 2020 10:10:19 -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 B79F73A0796 for <>; Sat, 22 Feb 2020 10:10:16 -0800 (PST)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1j5ZBI-000638-FM for; Sat, 22 Feb 2020 18:07:12 +0000
Resent-Date: Sat, 22 Feb 2020 18:07:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j5ZBD-00062N-NJ for; Sat, 22 Feb 2020 18:07:07 +0000
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j5ZBB-0003Sp-FV for; Sat, 22 Feb 2020 18:07:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1582394805; bh=vsP8LetS6xVsSuKUQiFzuocUIsFNK0xeBzNLcrTNO4c=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=YA3IJ1PTxML7fK4zQQNK/59noJjigh23Uf2d0JR0PTmupZOJPGmQuBFAgXtTRShp0 c4tCo+GmQz6Db01Wbd3FwEhIsXnkc25g5Xa2VrXARRJnCdlYj4P2IAnfyEfoxh5xQb 2JONZD+BRnaLrknBeR83GmK0tFh2zbUenNv2tGt0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MTRQq-1izx0r25xU-00ToA1; Sat, 22 Feb 2020 19:06:45 +0100
To: Tommy Pauly <>, HTTP Working Group <>
References: <>
From: Julian Reschke <>
Message-ID: <>
Date: Sat, 22 Feb 2020 19:06:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:YbZTlPO8oRsGJd6F0FrrNEvxgZc8oRfv4NaEQx6tRHNuPmEBNJC ETB41V7tEQEA98Iexq8WpRiDnYhxsVipBI3gCFfRw/95eUrgAwtStE3h5GaJqJ8Qrfh/fzd 8Oe2WFKML5NW5mkipRtsXhbbu5sryPqY3YhVC6mrpKPt92JLsLN3kustp0jQs1n+9LPYkY5 ubSo+qcH6DfUcPSFEVSyw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:ric1893uQNE=:rqRmQNmXzMBaRtcGx7cyD5 IJEaBZZiluyTyysDmn4ys/Czlj4EyD3iVLmZiBPBxJMOfou5B+xIbhwgk53Ty1urqlQC2WGy3 ahvgHOdskqKlsUxuBoGI0AzdGJ4zw3twSPe3+GsFwbJ9qiRnLOrJZl2gMhwc7bUnnqsVVxFA7 jmjGlgkFCJxXBeo/8GNh31sGFOkukLZdb5EsRWuZXLa4XbEmLL1cWYs4yQNFy6qA/nQQon133 uUj9UUORq7Jf9CTpSosfwzvZZjO5GCSb14Q87TonLreCyuIM7pF37TlXJqaf8cDfz9/nkSocl r5uGrYJJ3zWTy1sFTS6c5cX5Cc7GEWIIQkY+3EU/r1BLEeSsqzYluXZgHuFg0IVyHpbayXFRX PjeCJu6wWRVUdo3vLUJnQX3o8fdDVbqzMX58S9zONtrjL523NcsedoHxqwRjX4JcmrbtQCzUv 9/zT29eKIVyMoRPxNTdtvwiah31V5F3T1w/5wmAeJ8Rvl7J8hr8kX2otn+qRvNMYtTlO2Aobx k7fh+cnCKFvWfMWoDgoSemyB7+OPWhcFbY1B7uen+xdFS9lV1l+/fpikkhNBH/cGN4/i0BK93 YGhBbO0dH5/W5kK3a7BJVpJ6QOfH5d/04NE4ORwl0R3yJEB+tFnxLhuq6ntJF+42BK9JcvWJu NUgRIYXWE+6+ZFUchrnA6/f6tHAbK5w7ejKBesCunmMY41XRV0Ie2q+QQnV7vRS/F/qvV9J/5 InXHXEC3f94NU8087Itn0OjiomxzOBdFmzljx6WJlYlmHSIfr3taFsWs5BqztOOIYGp9c+gau hDK7VWH08uq4gv/gYJg0t/cYQjSAf2nSHSGnpI5yFltgj12VBkNgCpyMRwUWFSD3eZ6/gIeNM jy4mLuwmsfIWF0uyO3aSG3olkVuMmJKnFSISqY/b26nWF31DkjzUZi/n8mN0Jz4+JEyvSLjFz yfzYAkFiNYcBkQQfCXDqxowfrTFAAKE2FoByrPVEN+zDztIurfa7mMv8fseDZJN7uQpLwm4Hp RCi3r54JDYQG6SAdwaKnayV0zNHEjfnj0iobkSr42x8Q0kmDzwHCc4MRHM+phylS9lavRQaYf 7yWmm4pFDYxIONmajklqhxCL3/BWmjpJTlNEoTwrhm0F8m74q/I813dQ1Ju8QQoWkN7Dnb92N 1hnTpkNrWOhxsJBR+F+LLVnbDWj282rDzy4z+hN0TeF8KNb2VtHTqFSQK3gv/HSu0vk1OyJ/r ZIq9KRoHnq3iZbqgB
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1j5ZBB-0003Sp-FV 158ecd76cee4ed523b230324142906c5
Subject: Re: Working Group Last Call: Structured Headers for HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/37373
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 29.01.2020 18:11, Tommy Pauly wrote:
> ...

Below is my (slightly late feedback).

I was going to ask that the spec to be aligned with the recent
terminology clarification we did in the core specs (and which are not
yet published).

In fact, this is already addressed in the editor's draft, see current
diffs at
In encourage all participants to review these changes...

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 did not really review the algorithms; this essentially requires
writing code. I'm not really happy with the statement that in case of
conflicts, the algorithms have higher precedence than the ABNF.

Other than that; I found one major issue:

In 3.3.4:

   sh-token = ( ALPHA / "\*" ) *( tchar / ":" / "/" )

This should be

   sh-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )


Minor issues:

In Section 1:

At the end of the section (top level), there should be a paragraph break
between the two sentences (so that each Section 2, 3, and 4 are treated

In Section 1.1:

"In doing so, uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from
[RFC5234]. It also includes the tchar rule from [RFC7230]."

...should say..: "In doing so, *it* uses..."

In Section 2:

"Specify the type of the header field itself; either Dictionary (Section
3.2), List (Section 3.1), or Item (Section 3.3)."

Maybe sort by section number (swap Dictionary and List)?

Further down below it talks about the letter "Q" and the letter 'q'.
Please make the quoting consistent.

In the example spec text:

> "fooUrl" contains a URI-reference (Section 4.1 of
> [RFC3986], Section 4.1). If its value is not a valid URI-reference,
> that URL 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.

1. remove ", Section 4.1"

2. use of "URL" comes as as surprise here, maybe just say "field value"

In Section 3.1.1:

"In HTTP headers, inner lists..." - I was going to say that this seems
to be unnecessary verbose (here and in other places), but this has
already been fixed in the latest editor's draft.

In Section 3.1.2:


parameter     = ";" *SP param-name [ "=" param-value ]


"...parameters are separated from their item or inner-list and each
other by semicolons."

So there's an unfortunate mismatch between the ABNF production
"parameter" (which already includes the ";") and the use of "parameter"
in the prose. Maybe worth addressing in the ABNF.

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?)

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...

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.

In Section 4.1:

Item 2 and 3 should be swapped (to reflect the order of the definitions
in the spec).

Item 5 seems to be unreachable by definition.

In Section 4.1.3:

Section references in the list should be wrapped in "(" and ")"

In Section 5:

s/draft/specification/ or "document"

Appendix A:

Acknowledgements should be in a unnumbered appendix at the end.

That said, is mentioning exactly one WG member the right thing here?

Appendix C:

> A generic implementation of this specification should expose the top-level parse (Section 4.2) and serialize (Section 4.1) functions

Maybe swap the two parts (Sections mentioned in reverse order really
trip me up)

Best regards, Julian