Hm. I've always wondered about the percent double-encoding problem, where the "%" in "%2B" double-encodes to "%252B", which might require the mandatory server implementation then. I do think that because "git://git.gnome.org/git+" was working, something on the server was going right. On Mon, Jul 26, 2010 at 2:35 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > On Mon, Jul 26, 2010 at 18:22, Jasper St. Pierre <jstpierre@xxxxxxxxxxx> wrote: >> 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. > > In my example? Nowhere, but I used : and @, which are also reserved > characters. > >> 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 '+'. > > Yes, that's not supposed to work. But you should be able to access > "test+2.txt" using /test+2.txt and /test%2B.txt and > /%74%65%73%74%2B2%2E%74%78%74 for that matter. > > git-daemon only seems to handle the first form. Which is probably a > bug, maybe it doesn't *have to* URI unescape its arguments, but it's > probably a good idea anyway. E.g. some systems that handle URIs will > convert : to %3A automatically when passing them through. That would > break a git URL. > >> 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. > > I don't really have an opinion on what we should do. It's not a > problem for me, I'm just noting how it could break, and that maybe we > should try harder and support URI escaping where we handle URLs. > -- 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