- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 22 Apr 2015 17:03:29 +0200
- To: Zhong Yu <zhong.j.yu@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "Roy T. Fielding" <fielding@gbiv.com>, Barry Leiba <barryleiba@computer.org>, RFC Errata System <rfc-editor@rfc-editor.org>, Pete Resnick <presnick@qti.qualcomm.com>, Mark Nottingham <mnot@mnot.net>, Simon Schüppel <simon.schueppel@googlemail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Apr 22, 2015 at 08:55:06AM -0500, Zhong Yu wrote: > Well, Willy you are right that we cannot change a rule that has been > in effect for 20 years. If a parser doesn't follow the rule, it is a > bug, and it needs to be fixed. Yes. And RFC7230 says that we should not emit folded header fields anymore IIRC so we don't need to recommend how to emit them either. > Out of curiosity, I constructed the following response, and tested on > 5 major browsers > > HTTP/1.1 200 OK\r\n > Connection: close\r\n > Content-Type: text/plain;charset=UTF-8\r\n > <SP>\r\n > Server: test-folding\r\n > \r\n > 123456789 > > IE displays the response as > > Server: test-folding\r\n > \r\n > 123456789 > > That doesn't seem right. Indeed, that deserves a bug report. I don't know if that can be used as a content smuggling attack to send improper responses in data that have not been validated by an upstream proxy for example and which would be parsed as the response to the second request. That said, for those to appear like a valid response, the upstream proxy would need to accept something with spaces in the header names, which is unlikely to happen if it behaves properly on header folding (in general they're either very lax or very strict). Thanks, Willy
Received on Wednesday, 22 April 2015 15:04:08 UTC