- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 5 Jun 2013 07:36:00 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Roberto Peon <grmocg@gmail.com>, Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Julian, On Tue, Jun 04, 2013 at 10:04:23AM +0200, Julian Reschke wrote: > On 2013-06-04 09:50, Roberto Peon wrote: > >A search for regular expression (or synonym) and url will bring up > >numerous examples which would be broken by this change. > >It is certainly not every one, but numerous, nonetheless. > > > >Here is one example: > >http://net.tutsplus.com/tutorials/other/8-regular-expressions-you-should-know/ > >-=R > >... > > Yes, but what's the exact breakage except for one component not > processing that edge case? It's an edge case after all? Interesting case, at least it breaks haproxy's path extraction, which relies on 2616. When you need to check the path from a request, haproxy does this : 1) skip the scheme and "://" 2) skip user:pass@host:port 3) look for the first "/" 4) return everything from the first "/" to the first "?" or end of the string. So "http://example.com?query=foo/bar" will return "/bar" as the path of the request instead of an empty string or "/". BTW, is "/" supposed to be the abspath here, or just something empty ? I'm asking because haproxy returns a pointer to the beginning of the string and a length, so if the response is "/", we don't have it in this request, so probably the best thing to do would be to "fix" the request to insert the "/" before "?". > Me thinks it's better to be (a) consistent with generic URI parsing and > (b) what important components already do (UAs, http servers etc). I agree. Using a generic parser is important in that it avoids future incompatibilities as in the example above which was based on 2616. Best regards, Willy
Received on Wednesday, 5 June 2013 05:36:29 UTC