Subject: Re: Working Group Last Call: Structured Headers for HTTP

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Mar 2020 15:17:39 +1100

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 2 Mar 2020 05:45:05 +0100

On 02.03.2020 05:17, Mark Nottingham wrote:
> ...
> ...

Thanks alot!

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Mar 2020 16:11:54 +1100

> On 25.02.2020 01:34, Mark Nottingham wrote:
>> ...
>>> Or just "Structured Field Values for HTTP".
>> 
>> That's better, and I think I can live with it -- as long as we establish that "Structured Headers" is an alias for it (and still use that in-spec, as it's in a number of places). Make sense?
> 
> WFM.

See:
  https://github.com/httpwg/http-extensions/commit/d5787b89820cb