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

[Julian Reschke <[e-mail]>]

On 15.05.2020 17:13, Willy Tarreau wrote:
> ...
> I agree with this. Typically the problem is that clients could abuse
> intermediaries to transform their requests. So adding a hint for
> intermediaries here would help. If it's explicitly written that a
> recipient is allowed to reject a request having such invalid header
> value, I'm fine telling haproxy users that what haproxy does on this
> or that header field is correct and spec-compliant. Otherwise the best
> I can do is encourage them to add blocking rules it if they dare do it.
>
> The problem is always the same: intermediaries are forced to remain as
> transparent as possible (even violating specs sometimes) because when
> inserting them results in breakage, it's necessary their fault. Here we
> have an opportunity to allow them to be a bit stricter, we really ought
> to take it!
> ...

+1

Related to this: it just occurred to me that:

   Test: Foo
   Test:
   Test: Bar

yields different results for fields using HTTP's list notation, and
structured header fields.

In the former case, the combined value is equivalent to

   Test: Foo, Bar

while in the latter case, the field is malformed.

I *really* think it would be better if structured header fields would
actually be "proper" applications of the standard HTTP list ABNF.

Best regards, Julian