- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 24 Dec 2016 10:25:02 +1300
- To: ietf-http-wg@w3.org
On 24/12/2016 7:16 a.m., Mark Nottingham wrote:
>
>> On 23 Dec. 2016, at 12:39 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> On 2016-12-22 19:38, Poul-Henning Kamp wrote:
>>> --------
>>> In message <CAK_TSXLJcDkUCpn5f79DBtnGjjPLtb1fEv_-Akfg4cPbboFVvg@mail.gmail.com>
>>> , Ian Clelland writes:
>>>
>>>> With JFV, I'd declare a policy with a header value like this:
>>>>
>>>> {"feature1": ["http://origin1","http://origin2"]], "feature2": ["http://origin3", "http://origin4"], "feature3": []}
>>>
>>>> Trying my best to shoehorn this structure into CS, I do notice that nothing
>>>> in the grammar or the text says that duplicate identifiers in an
>>>> <h1_element> aren't allowed, so I suppose I could write something like this:
>>>>
>>>>> feature1;o="http://origin1";o="http://origin2",feature2;o="http://origin3";o="http://origin4",feature3<
>>>
>>> That's how I would do it as well.
>>
>> Using identical parameter names sounds like a bad idea; I'm not aware of any header field that currently uses this format, and it also seems to contradict the "dictionary" data model.
>
> Link allows it, and IIRC some link relations take advantage of that (although I can't think of their names ATM).
>
AFAICS for most of the headers that will benefit from generic syntax
parsing instead of custom parsers the desirable behavour is to normalize
foo;o=X;o=y down to just foo;o=y to prevent foo;o=X vs foo;o=y
interpretation differences by various recipients and nasty values being
smuggled through middleware.
If we can avoid having parameter name duplication, that would be a good
step towards uniform handling of these smuggling protections.
Amos
Received on Friday, 23 December 2016 21:25:45 UTC