Re: empty lists?, was: Last Call: <draft-ietf-httpbis-header-structure-18.txt> (Structured Field Values for HTTP) to Proposed Standard

On 19.05.2020 01:20, Mark Nottingham wrote:
>> On 19 May 2020, at 7:23 am, Benjamin Kaduk <> wrote:
>>>> You saw
>>>>     An empty List is denoted by not serializing the field at all.
>>>> right?
>>> That's about serialization.
>>> 4.2.1 seems to parse an empty string into an empty list.
>>> AFAICT, that's in conflict with the ABNF.
>> Thanks for clarifying.
> As per S 1.2 [1], the ABNF is not for parsing; it's for 'illustrat[ing] the range of acceptable wire representations.'
> The ABNF requires at least one member because sending an empty field value is not good practice; it's not something we encourage.
> ...

So the real inconsistency here is that sending an empty value is not ok
(forbidden?, not encouraged?), but an empty string is a valid parser input.

That is confusing; if that's really intended, it should be explained
somewhat more. AFAIC, it would be way easier just to align "what can be
in a field value" with "what the parser accepts as input".

> ...

I note that there is a test called "empty list" at

>     {
>       "name": "empty list",
>       "raw": [""],
>       "header_type": "list",
>       "expected": [],
>       "canonical": []
>     },


> raw: An array of strings, each representing a header field value received

I understand that the tests are not part of the spec, but this seems to
support the case that empty field value should be accepted.

Best regards, Julian

Received on Tuesday, 19 May 2020 02:50:28 UTC