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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
