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