- 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