- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 30 Apr 2013 07:52:51 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Tue, Apr 30, 2013 at 01:18:43PM +1000, Mark Nottingham wrote: > So, I'm not hearing you say "don't make this a MUST" -- just noting that some > broken software out there; correct? Amos' last sentence makes me understand "please don't make this a MUST" : > The actual security worst-case risk of this undeterminable, but its > not going to be good for the transaction at the best of times And I also agree with him that the wording currently is ambiguous because it can either be understood as "servers and intermediaries should do this since they're accepting user-typed URIs" or as "clients should fix user- typed requests before sending". Thus in order to avoid any ambiguity, I would propose two sentences instead of one : > For robustness, software that accepts user-typed URI should attempt > to recognize and strip both delimiters and embedded whitespace. Would become : Clients MUST NOT send user-typed delimiters and embedded whitespaces as-is in URIs, and SHOULD either encode them, strip them. Alternatively they MAY simply refuse to perform the request. Servers and intermediaries MUST NOT try to fix embedded spaces and delimiters in URIs, as doing so could lead to interoperability issues and make several components in the chain understand different things. When a request does not parse exactly as defined in the ABNF, an error 400 (Bad Request) MUST be returned to the client. Comments ? Willy
Received on Tuesday, 30 April 2013 05:54:58 UTC