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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html