- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 31 Oct 2022 15:40:59 +0100
- 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