- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 15 May 2020 17:20:52 +0200
- To: Willy Tarreau <w@1wt.eu>
- Cc: Mark Nottingham <mnot@mnot.net>, last-call@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, barryleiba@gmail.com, draft-ietf-httpbis-header-structure@ietf.org
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
Received on Friday, 15 May 2020 15:21:39 UTC