Re: URL decoding changed semantics of + in URLs

From: Jasper St. Pierre <jstpierre@mecheye.net>
Date: Jul 26, 2010, 18:22 UTC
Message-ID: <AANLkTimRrpiv7cu=j598K3x4h3UGW7-Hik6-6jA8R_5J@mail.gmail.com>
In-Reply-To: <AANLkTikmFVHeMVEgj_G5h8VMNaw0zIm0Ol-vC1ffc45v@mail.gmail.com>

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.

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 '+'.

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.

On Mon, Jul 26, 2010 at 1:57 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 34 quoted lines

> On Mon, Jul 26, 2010 at 15:40, Jeff King <peff@peff.net> wrote:
>
>> As Jasper noted, "+" is a reserved character, which means "gtk+"
>> probably _should_ be escaped. But clearly it doesn't happen in practice,
>> and I am more interested in not breaking current use than in nitpicking
>> with a standard.
>
> Reserved characters only have to be escaped in certain contexts, from
> RFC 2396:
>
>   Many URI include components consisting of or delimited by, certain
>   special characters.  These characters are called "reserved", since
>   their usage within the URI component is limited to their reserved
>   purpose.  If the data for a URI component would conflict with the
>   reserved purpose, then the conflicting data must be escaped before
>   forming the URI.
>
>      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
>                    "$" | ","
>
> E.g. @ is special in the hostname part (http://user@example.org), but
> writing http://example.org/Git@Big%20companies:%20A%20Study is just
> fine.
>
> Which is why curl passes it along literally, it *can* escape them, and
> real webservers like Apache handle reserved characters equivalently
> (in their unreserved contexts) whether they're escaped or not, but the
> git-daemon at git.gnome.org evidently doesn't implement RFC 2396
> carefully enough.
>
> So we shouldn't escape + for backwards compatibility and because it's
> not necessary, but we should probably also fix git-daemon to accept
> both forms if that hasn't been done already.
>