Re: URL decoding changed semantics of + in URLs

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.