W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: Working Group Last Call: Structured Headers for HTTP

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 2 Mar 2020 15:17:39 +1100
Cc: Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <51DBD45E-946F-4641-9573-12BF2550B4FB@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>


> On 25 Feb 2020, at 7:06 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 25.02.2020 07:13, Mark Nottingham wrote:
>> 
>> 
>>> On 25 Feb 2020, at 5:08 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> 
>>> I understand that. What trips me up is that we we have to different
>>> cases: one in which the shorter notation MUST be used, one in which it
>>> MUST NOT be used. Am I the only one who thinks that this is sub-optimal?
>>> 
>>> In a perfect world, the serialization should not depend on the context
>>> it appears in. I understand that this is a trade-off, but it would be
>>> good to see more context about how we got there, and whether
>>> alternatives were discussed.
>> 
>> If you're referring to the case of a Boolean as a Dictionary value (and it would be good if you confirmed that this is what you had in mind; if you're talking about Booleans wherever they might appear, I don't know how that would work), it was considered, but IIRC it would have required a substantially more complicated parsing algorithm, because of cases like this:
> 
> Yes.
> 
>> Example-Field: ;param=on-default-boolean
>> 
>> Parameter values are comparatively simpler, because they can't have any further substructure.
> 
> I don't quite get the example. Example-Field: ;param=on-default-boolean
>> 
>> Parameter values are comparatively simpler, because they can't have any further substructure.
> 
> I don't quite get the example. In the spec I see:
> 
>  Example-DictHeader: a=?0, b, c=?1; foo=bar
> 
> If this would be instead:
> 
>  Example-DictHeader: a=?0, b, c; foo=bar
> 
> ...what would break?

It was concern about re-working too much of the parsing algorithm. However, looking at this again, I think we could replace:

~~~
   3. Otherwise:
      1. Let value be Boolean true.
      2. Let parameters be an empty, ordered map.
      3. Let member be the tuple (value, parameters).
~~~

With:

~~~
   3. Otherwise:
      1. Let value be Boolean true.
      2. Let parameters be the result of running Parsing Parameters {{parse-param}} with input_string.
      3. Let member be the tuple (value, parameters).
~~~

I've created <https://github.com/httpwg/http-extensions/issues/1083> to track this and gather feedback.

Cheers,


--
Mark Nottingham   https://www.mnot.net/
Received on Monday, 2 March 2020 04:18:01 UTC

This archive was generated by hypermail 2.4.0 : Monday, 2 March 2020 04:18:02 UTC