Re: Empty lists in Structured Headers (#781)

[Amos Jeffries <[e-mail]>]

On 3/05/19 5:41 am, Willy Tarreau wrote:
> 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.


Nod. This is the first I recall the topic coming up.

That said. I am aware of several technical reasons for having explicit
handling of empty headers mentioned - at least somewhere centralized.

* empty is not always considered by implementors. That leads to
interoperability differences which can provide privacy leaks for
fingerprinting the HTTP agents themselves.

* assumptions by implementations not expecting to see empty values can
result in security flaws. I have seen certain empty headers crashing
servers and sometimes dynamic sites.

* It is a waste of bandwidth, memory, CPU cycles to any agent receiving
empty headers.


RFC7230 omits field-value from the list of protocol elements that are
called out for special attention to value lengths - though that text
does say the list is incomplete. So this spec about headers or a revised
RFC7230 descendant would seem to be good places to set some formal
handling requirement (ie MUST accept, MUST NOT send [except when
required. eg, Host]).


Amos