Re: Empty lists in Structured Headers (#781)

[Willy Tarreau <[e-mail]>]

On Thu, May 02, 2019 at 04:56:39PM +0000, Poul-Henning Kamp wrote:
(...)
> Then we retreated further by restricting the depth to one, hoping
> to at least curb the enthusiasm for inventing new syntax in this
> space, and through successive cuttings of heels and toes, the SH
> draft we have now has resulted.
> 
> If you have any ideas how this could have gone better, I'm all ears ?

Guys, I think the problem can easily be addressed. I think that many
of us will agree that there are some reasonable limitations that add
simplicity and/or security at the expense of tradeoffs that should
almost affect nobody, such as the limited range of integers.

I think that the opposition against support of empty values only came
from an almost inexistent need at a moment where the spec looks quite
polished, resulting in limited motivation to do some further work on
this. I continue to think it's a bad idea to explicitly exclude them
as the time saved by *not* working on this point is wasted discussing
why it's not being worked on, and will be wasted 100 times more once
the document becomes an RFC, to deal with the ugly workarounds that
people will have invented and/or how to find a safer update to the
spec that remains backwards compatible with deployments.

I don't think we've discussed a *technical* reason for not supporting
these, most only taste based on (possibly inappropriate) proposals
coming out of a few of us' heads. Let's try again to see how that
could be included without breaking things apart nor creating traps
for implementers, and see if the resulting solution looks acceptable
or not. If it does not, at least we'll have a compelling reason
explaining why this is not supported and to encourage users to stop
emitting or dealing with these. Otherwise we'll have a better and
safer coverage, which is always welcome.

Just my two cents,
Willy