Re: Working Group Last Call: Structured Headers for HTTP

[Mark Nottingham <[e-mail]>]

> On 25 Feb 2020, at 7:06 pm, Julian Reschke <[e-mail]> wrote:
> 
> On 25.02.2020 07:13, Mark Nottingham wrote:
>> 
>> 
>>> On 25 Feb 2020, at 5:08 pm, Julian Reschke <[e-mail]> 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/