Re: URL decoding changed semantics of + in URLs

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 26, 2010, 17:57 UTC
Message-ID: <AANLkTikmFVHeMVEgj_G5h8VMNaw0zIm0Ol-vC1ffc45v@mail.gmail.com>
In-Reply-To: <20100726154041.GA18762@coredump.intra.peff.net>

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.