Re: URL decoding changed semantics of + in URLs

[Jeff King <peff@peff.net>]

On Fri, Jul 23, 2010 at 03:18:30PM +0200, Thomas Rast wrote:

> As pointed out by Jasper St. Pierre on #git, it is no longer possible
> to clone
> 
>   git://git.gnome.org/gtk+
> 
> because your 9d2e942 (decode file:// and ssh:// URLs, 2010-05-23)
> decodes + characters in URLs to spaces in the http style.  It was
> later fixed by ce83eda (url.c: "<scheme>://" part at the beginning
> should not be URL decoded, 2010-06-23) but the later part of the url
> still decodes + as space.
> 
> The tests that go along with the commit make it clear that it was an
> intended change.  But the interesting thing is, I cannot find any
> reference in any RFC that + must have this meaning.  In particular,
> 
>   http://www.ietf.org/rfc/rfc2396.txt
> 
> doesn't say much about + and the only escaping defined is the usual
> %xx style.  So is there a standard that mandates this, or was it just
> a well-meaning but unnecessary backwards incompatible change?

Sorry for the slow reply. I am in the middle of moving and just got a
usable machine running.

I think it is well-meaning but unnecessary. That is, I think %-decoding
is probably still a good idea, and I just dragged '+'-decoding along out
of cluelessness. I thought I cross-checked with what curl was doing to
http URLs, but now I can't even get it to do anything but pass the path
component literally to the webserver. So I'm really not sure what I
tested before.

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.

So I agree with the spirit of your patches, and reading over your v2, it
looks fine to me, but I didn't do any extensive testing.

-Peff