- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 20 Sep 2010 10:27:46 +0200
- To: "Willy Tarreau" <w@1wt.eu>, "Mark Nottingham" <mnot@mnot.net>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>, "Roy Fielding" <fielding@gbiv.com>
On Mon, 20 Sep 2010 07:57:56 +0200, Mark Nottingham <mnot@mnot.net> wrote: > Proposed: > > 3. If a message is received without Transfer-Encoding and with > either multiple Content-Length header fields indicating different > lengths or a single Content- > Length header field with an invalid value, then the message > framing is invalid and treated as an error to prevent > request or response smuggling. If this is a request message, the > server MUST respond with a 400 (Bad Request) status code and then > close the connection. If this is a response message received by > a proxy or gateway, the proxy or gateway MUST discard the > received response, send a 502 (Bad Gateway) status code as its > downstream response, and then close the connection. If this is a > response message received by a user-agent, it SHOULD NOT > be used, but if it is the message-body > length is determined by reading the connection until it is > closed, and the user SHOULD be informed of the problem. > Subsequent responses on the connection MUST NOT > be used. I'm not quite familiar with our code here, but if I understand the bug report below most (if not all) browsers do not implement any of the above. That does not seem good. Also, a SHOULD seems way too strong; even if we would report HTTP errors in an error console in most cases the user will not be informed at all. If I remember correctly, HTML5 typically uses MAY for such cases and a MUST for conformance checkers. > Also, FYI: > https://bugzilla.mozilla.org/show_bug.cgi?id=597706 -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 20 September 2010 08:28:52 UTC