Re: Revising Structured Fields: scope

On Thu, Oct 13, 2022 at 05:42:37AM +0000, Poul-Henning Kamp wrote:
> --------
> Willy Tarreau writes:
> 
> > I would really
> > like it if we would remove that limitation so that we could hope to more
> > easily retrofit other fields there, and it doesn't seem like too complicated
> > change to me to simply add "sf-empty" to the bare-item definition, which
> > would likely solve this.
> 
> I fear that codifying that would encourage more headers with
> such behaviour, which I assume we do not want ?

I don't think it would encourage this because I don't think the rare header
fields that need this nowadays predicted this use, it was just the result
of an overlooked corner case that later left only this option (i.e. reject
a request if the field is absent, or have a default value if not set). I'm
not aware of a single field that was deliberately designed as having an
empty value as something intentional. And it would be annoying if in the
future some fields designed to fit into the SF representation start to
appear as empty because of a similar corner case and suddenly the SF
parsers fail on them while non-SF ones are fine with that. And that's
precisely what currently refrains me from implementing SF: breaking
interoperability where alternate solutions would be fine.

> I would far prefer to let the very few headers which has this behaviour
> be special-cased in their own definition.

It may extend to one new field every 10 years just because someone
decided that the field is mandatory, while the sender has no idea about
what to put into it. That's precisely what I want to secure for the long
term.

> If I am wrong about that, and if you mean something like adding in 4.1:
> 
> 	0.   If the structure value is sf-empty, return an empty string.
> 
> and in 4.2:
> 
> 	1a.  If sf-empty is a permissible field value and input_string
> 	     consists entirely of SP characters, return sf-empty.
> 
> That seems mostly harmless to me.

That would be fine for me. The second point could even be simplified to:

  2a. If sf-empty is a permissible field value and input_string has no
      remaining characters, return sf-empty.

> If you want sf-empty anywhere else, I am a firm NO, because it would
> require significant work to redefine inner_list and maybe other places.

I agree. The only valid reason for an empty header field is to distinguish
it from an absence which would carry a different semantic. So there's no
reason to have an empty list item for example, as it would be equivalent
to a first non-empty one and a second empty one. And for headers folding
into lists, we could require that empty ones are just skipped in presence
of at least a non-empty one, and that's already mandated by 9110#5.6.1
which forbids production of empty list elements by the way, so we should
be fine.

Thanks!
Willy

Received on Thursday, 13 October 2022 06:31:56 UTC