On 5/28/2014 10:14, Stephan Beal wrote:
So fossil is incorrect to convert + to space if it is before the first
? in the URL.
Interesting question, especially in the face of this case:
/wiki/foo
equivalent to ===>
/wiki?name=foo
the first one has no QUERY_STRING but is, internally, treated as if it
had been passed name=...
I don't see that there is ambiguity here at all. Doesn't your case
happen after URL parsing? URL escape decoding should happen *before*
the URL is parsed.
If we have "fossil server" running alone, with no SCGI or reverse proxy
in front of it, this URL:
http://myserver.org:8080/wiki/foo++
should have /wiki/foo++ parsed from it, leaving the ++ untouched because
it is not part of the query string.
The fact that /wiki/foo++ gets turned into wiki/name=foo before sending
it to the wiki handler is immaterial. The wiki handler shouldn't be
doing any URL decoding on its own. It must assume that the URL is in
its final form already.
If I have a wiki article called "foo++" and want to access it with query
string syntax, I *must* encode the + signs:
http://myserver.org:8080/wiki?name=foo%2b%2b
The URL decoder turns that into ...wiki?name=foo++ before sending it on
to the wiki handler, which dutifully looks up the foo++ article.
Where's the problem?
SCGI doesn't complicate this at all. Fossil knows it is behind another
web server in that case, so it must disable URL decoding, else it can
end up doing double decodes:
"http://myserver.org:8080/wiki?name=foo%2b%2b";
"http://myserver.org:8080/wiki?name=foo++";
"http://myserver.org:8080/wiki?name=foo "
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
