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

Re: draft-ietf-httpbis-header-structure-00 for general structured data

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 24 Dec 2016 08:07:34 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Ian Clelland <iclelland@google.com>, ietf-http-wg@w3.org, Poul-Henning Kamp <phk@varnish-cache.org>
Message-ID: <b12fe972-836a-b3df-51a5-b5bc661e6c12@gmx.de>
On 2016-12-23 19:16, 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).

<https://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.5.3>:

"The relation type of a link is conveyed in the "rel" parameter's value. 
The "rel" parameter MUST NOT appear more than once in a given 
link-value; occurrences after the first MUST be ignored by parsers."

Best regards, Julian
Received on Saturday, 24 December 2016 07:08:26 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 24 December 2016 07:08:34 UTC