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

[Willy Tarreau <[e-mail]>]

On Fri, May 15, 2020 at 10:20:21AM +0200, Julian Reschke wrote:
> > > IMHO it would be better to allow those recipients that *can* detect the
> > > brokenness to reject these fields.
> > 
> > The problem is that many recipients won't be able to. This includes not
> > only when an intermediary combines multiple field lines into one, but also
> > when a server or library does so (which is more common IME).
> 
> Yes.
> 
> > We already have potential inconsistency in whitespace caused by such
> > combination. I'm reluctant to add another dimension of inconsistency
> > (whether or not the SH^HF implementation can recognise this situation and
> > reject early).
> 
> Understood, but I would see it this way: having *some* implementations
> able to detect broken input is better than nobody detecting it, because
> this way the problem might be fixed.

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!

Just my two cents,
Willy