W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: combined field value, Re: Working Group Last Call: draft-ietf-httpbis-message-signatures-13

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 31 Oct 2022 15:40:59 +0100
Message-ID: <111cf860-bbda-1c02-a5b7-81c76af7d263@gmx.de>
To: Justin Richer <jricher@mit.edu>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Am 31.10.2022 um 15:33 schrieb Justin Richer:
> Hi Julian, thanks for this writeup of this issue. Multiple-valued fields have been potentially trouble from the start of this work many years ago.
> After re-reading the text in RFC9110 section 5, but especially 5.3, the normalization rules are consistent with the advice of " For consistency, use comma SP”, but an intermediary could in fact combine field values without spaces on the way through. I think what we want to do is something like:
> 	HTTP fields that are known to be  "list-based fields” by the signer or verifier which have multiple values MUST have all values combined using the delimiter of “comma <SP>” as suggested by RFC9110. <warning about set-cookie goes here>
> So it’s still the “combined value” but it’s got very specific rails around it. What do you think of this approach?
> I agree that we might want to revisit this text in the HTTP semantics document, too. In my own limited practical experience, whenever the libraries I’ve used offer a pre-combined value, it always does the combination with “comma <SP>”, as shown in both examples and in the non-normative recommendations. I think that the fact that the examples do the same, in spite of the normative text technically allowing other options, is a practical consideration for implementors.
>   — Justin

Well, there's nothing in the spec that guarantees that this (adding the
OPTIONAL SP) will happen. I'm not sure it's a good idea to rely on it.

A sender can always make things robust by making sure that there's only
a single instance of the field...

Best regards, Julian
Received on Monday, 31 October 2022 14:41:18 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC