W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: HTTP URI in the form of "http://example.com?query"

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>
Message-ID: <20130605053600.GB21058@1wt.eu>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC