Re: Working Group Last Call: Structured Headers for HTTP

Julian Reschke <> Tue, 25 February 2020 06:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B5573A0ADC for <>; Mon, 24 Feb 2020 22:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 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] 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 hvxMqUV5yHWf for <>; Mon, 24 Feb 2020 22:12:54 -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 DDD7D3A0ADA for <>; Mon, 24 Feb 2020 22:12:53 -0800 (PST)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1j6TPL-0000ai-H6 for; Tue, 25 Feb 2020 06:09:27 +0000
Resent-Date: Tue, 25 Feb 2020 06:09:27 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j6TPA-0000S9-Kn for; Tue, 25 Feb 2020 06:09:16 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1j6TP8-0004og-Hs for; Tue, 25 Feb 2020 06:09:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1582610933; bh=hD9vh+4PyhfFlQBD+xqpfqnB81IIYyvkWbKqITd/PN8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=V/J9Szc35YdI6D2IASK6TauuCuXkWwcWKZ/UgxL7Td5OWWRD3YvYR90rI0Yyo1VH3 Izxsfg5iUMBun2R2U1VVYTkNRBbYe2BK68B0StZfqdBUQmf/s0o72Q/0uAapv/Ay5e genjJFd5jiaqu4esyVnTolg+5nyrDZ0d1sZS0n78=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1MgNcz-1jd2OQ2pix-00hxSF; Tue, 25 Feb 2020 07:08:53 +0100
To: Mark Nottingham <>
Cc: Tommy Pauly <>, HTTP Working Group <>
References: <> <> <> <> <>
From: Julian Reschke <>
Message-ID: <>
Date: Tue, 25 Feb 2020 07:08:53 +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="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:W/mz1HwDJ5wTNTNhldFf2O9Ekf0kIMiOxskiaAkyOH0f97yA2Zo M7WsCALX6di4eCQufR9gkgwYTtWvs2FCjZhuywfLjGV5ycAlwwPzR4ihEN4WQLA54igmFVZ tCvYRetR87HelI0QOYhlETfM2vEIIEujsnj5WohnomDn0VhslCngZKm22/6sS15UtYecHBT hVMxHDg+/ffCLr+KP3e1w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:D0Qo3Ol1bYE=:pBHxcvzqgJ1jAbqcNHAdZW 3pzFj6Bx63eSyDftF3rheYVzo5XJUJRb0NlNf5UHnujAYwRVoZwde2TnLURp4XJEofdpYw3el unYvqinp7mXFdqjMFNIUx3CaagNT+jDmCeIBkMk7aYJKmXtDbmpbq7dhqnW2T6gcm8gAgouov RFaXQ8QKw/9IML5DDm3WSV/qxiZ6UEevAKCmPTM3CWOrzPzj4tZFA+74q7BQbijPRd6SwdVND +ghuc3tXAEiFldvWXm/LJ3JFLoNA+5oKZdQPGQWY0hk4gkGdVDfVeQGpPgBHTGG0ZqZsCvFIK phYSGutmH9r3IqOlMu5nPpQR0kwG23ng57Iqx1j6Ag85pHhJYty7pr2XcQR7sI0zg7BBLTvdx +g+54ay6S+iqRb9CMbsEwvgAVziclInn7xUIGjKbzShtx8seXp8jF8GCwq8j9FZIVHgvKoNA7 SVzz71GealRtM+JGNR8kXxcbBGnvCf65N5Wwl2itEjYQ4+CgBcmNzDSoJJTgjCLEnrDqQap+U 5bG5WbmBq/KGAHSw6WFOfAQjhwEA7s/jOM/3dbJD7W+qOJUDuzx2QgnVhlzBUqXEHSdFR6/VN PsjLTi6y1wgH7erFFzfg+/REVzO8RVLQjgyFcU1nhKiBfhFVqhp/zuxirtcxXZu4nBSIqtd0k VKAFNvNYb8O7X4dRmlTTvKm7qqSlOt9+uk9RtPYF6jqEjF2cXuGDXfKFsApVvXJzR/nUPfmfH KN1pZw9LJnwVpeieGPypkFp8gjk0Exhp0ZBJ8CzYZzK+1iv+53EoHxdinDAL7QGz0zEVBLdVr P2zlnXIdlE5eCl6a8sr0Mtlrm19KGPycdHOG2w+I6wRFJepBNQBARJEIcVhKyYLCJzTTlrVCI 2U8PqmZIiIxhzGGeRBwSxLNlU01dnENew9ggo7vwI5gRAdSw/VJm+QXydPc4+roydqQ6QpY7H 2ZvCwBAi+0OgJp0vYjVVeEmSeFSlHSnhkvZB0dUEvCH5aVcLML3mySyzBtLLUAcO0xKcin0bP yQ6XWD556BtATdAuUErRkIFUfFVeXYYpPYLU7ETztpGXDJyDy+h3NIRZOzNcKtm0Qiif7WRZd YiEpy1WH/neZuWaaVCCvC7KTpbcIBcJIQPA8fsxgk7LzsKemGbeR+8N4960472+5GXrveXG6T Ea44q0Nn5Lq8eXis5oH9TQklEs/N4wUDsA3GrtYK+h/AF60tsg9rzAejBktdCjrc7sTUvQdAR dA1yeR6hFBrsfasRi
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: 1j6TP8-0004og-Hs fb1a8bcf2f302317b782f9c08665eecc
Subject: Re: Working Group Last Call: Structured Headers for HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/37386
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 25.02.2020 01:34, Mark Nottingham wrote:
> ...
>> 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.

I understand that. What trips me up is that we we have to different
cases: one in which the shorter notation MUST be used, one in which it
MUST NOT be used. Am I the only one who thinks that this is sub-optimal?

In a perfect world, the serialization should not depend on the context
it appears in. I understand that this is a trade-off, but it would be
good to see more context about how we got there, and whether
alternatives were discussed.

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

Looks good to me.

> ...

Best regards, Julian