Re: URL decoding changed semantics of + in URLs

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 26, 2010, 18:35 UTC
Message-ID: <AANLkTilDKIwcQ0OmXAihq8AkS7v31HseEI3BGTUyzl9v@mail.gmail.com>
In-Reply-To: <AANLkTimRrpiv7cu=j598K3x4h3UGW7-Hik6-6jA8R_5J@mail.gmail.com>

On Mon, Jul 26, 2010 at 18:22, Jasper St. Pierre <jstpierre@mecheye.net> wrote:

> Where is '+' used in the URL context? I don't see that it's a
> replacement for '+'
> aside from formencoded, which is from CGI, not HTTP or the URI spec.

In my example? Nowhere, but I used : and @, which are also reserved characters.

> I also can't access something called "test 2.txt" from Apache with
> "http://localhost/test+2.txt", so I don't think it's unescaping the '+'.

Yes, that's not supposed to work. But you should be able to access "test+2.txt" using /test+2.txt and /test%2B.txt and /%74%65%73%74%2B2%2E%74%78%74 for that matter.

git-daemon only seems to handle the first form. Which is probably a bug, maybe it doesn't *have to* URI unescape its arguments, but it's probably a good idea anyway. E.g. some systems that handle URIs will convert : to %3A automatically when passing them through. That would break a git URL.

> I don't think we should do anything about the '+' case, except where used in
> formencoded parameters (aka the "query string"), where it is used.

I don't really have an opinion on what we should do. It's not a problem for me, I'm just noting how it could break, and that maybe we should try harder and support URI escaping where we handle URLs.