Re: [httpapi] Structured Fields for HTTP APIs

[Julian Reschke <[e-mail]>]

On 04.02.2023 07:24, Mark Nottingham wrote:
>
>> On 2 Feb 2023, at 12:28 am, Julian Reschke <[e-mail]> wrote:
>>
>>>>>   [..] If headers with unknown
>>>>> syntax are a problem for existing tooling, how has that tooling survived
>>>>> the introduction of any new header over the past decade? [...]
>>>
>>>> the question in fact was a bit different - use SF to combine
>>>> multiple related things into a single field, or use multiple fields so
>>>> it's easier to extract the various parts.
>>>> With the latter approach you actually do not need a new field value
>>>> parser,
>>>
>>> Yes Julian, you got the point.
>>> In general, I question whether it is sensible to
>>> enforce SF usage in API contexts where consolidated practices
>>> (that we might like or not) already exist.
>>
>> Well, if the consolidated practice is to either use problematic
>> substring/regexp matches, or spreading things about multiple fields, I
>> disagree (not sure if this is the case here).
>
> That's one of the issues.
>
> You also need to consider all of the corner cases about combining multiple instances of a field -- even if a field only allows one instance, we often see that more than one occurs on the wire, so error handling needs to be defined. SF does this for you.
>
> Additionally, "simple" headers often need to be extended, at which point you have significant interoperability problems. SF again gives you an extensibility path.

Yes. And then there's escaping, whitespace, number overflows, whatnot.

> Regarding Date, I have to say I'm concerned. The HTTP WG had what I'd consider a strong consensus for the current unix date approach, but it's not clear to me whether it's actually going to be used. An unambiguous signal (yes or no) about whether this community will use it in its drafts would be helpful, IMO.

That's my recollection as well.

Best regards, Julian