Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On May 27, 2014, at 7:55 PM, Joel Bruick j...@joelface.com wrote: Richard Hipp wrote: I think that's an HTTP thing. In a URL, spaces are encoded as +. It's really an HTML form thing [1] that only applies to the query portion of the URL. In the path component, we technically should be percent-encoding spaces and leaving any instances of + alone, which would then allow you to reference such files normally. That's a much more involved fix that offers very little value, though. Just file this under the more you know.” Actually, I just came up with a use case where you want Fossil to handle + without URL-decoding it. If you have foo.md containing with something like this: ...but for more on that, see [the VC++ README](README-VC++.md). and you link to it with a doc URL, you want the generated HTML to link to README-VC++.md, not to “README-VC .md”. You can make it create the right link by replacing the + signs with %2b, but that makes foo.md harder to read in a text editor. One reason to use doc URLs in the first place is that you want to refer to documentation files you will ship as part of your distributed source code, so you don’t have to have their content in two places. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On Tue, May 27, 2014 at 03:46:30PM -0400, Richard Hipp wrote: On Tue, May 27, 2014 at 3:43 PM, Warren Young war...@etr-usa.com wrote: Hi there, I had a file called README-Visual-C++.txt in one of my repositories and wanted to link to the tip version of it from an outside web page. I discovered the doc URL feature in Fossil, but it didn't work with that file. Apparently there's some kind of data sanitization going on here that turns the +'s into spaces. I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. Strictly, space is only encoded as + in the QUERY_STRING part of a URL. So fossil is incorrect to convert + to space if it is before the first ? in the URL. It's an edge case, but it turns out that someone has hit it. If the filename really does contain + symbols, then the URL should have %2b for each plus. ex: http://localhost/doc/trunk/README-Visual-C%2b%2b.txt That's a valid encoding, but not a required one (outside of fossil). You could also validly encode the C as %43 and the . as %2e or %2E, and everything should continue to work. (But that usually isn't done.) The no-code-change answer is just to document that fossil requires that + be encoded as %2b everywhere in a URL, but that's probably not a great long-term option. f -- Francis Dalyfran...@daoine.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On Wed, May 28, 2014 at 01:08:26AM +, Joe Prostko wrote:
On Tue, May 27, 2014 at 11:31 PM, Warren Young war...@etr-usa.com wrote:
Hi there,
1. You don't need to do regex matching on the URL here. This does the same
thing more efficiently and more clearly:
location /demo_project/ {
I always write this as:
location ~ ^/demo_project {
myself. That way, it's a case-sensitive search where I don't have to
worry about the trailing slash, and it stops searching once it finds
/demo_project. I could be mistaken though, but I thought the way you
suggested wouldn't be as flexible.
This is nginx-config information now, and useful if someone wants to
use nginx as a reverse proxy for fossil. That's the (tenuous) link for
me putting it on this list...
The location lines above -- and the ones in the fossil documentation --
are all mostly equivalent if they are the only location blocks in the
config. (mostly would be exactly if they all ended with or without
the slash.)
Where they differ is if there is another location line, such as
location ~ php. In that case, if you request /demo_project/dir/file.php,
which location is used will depend on other things.
The proper nginx way would be to write it as two separate locations:
location = /demo_project {return 301 /demo_project/;}
location ^~ /demo_project/ { # all the rest }
although there is magic within nginx to make the first location
unnecessary in this case.
So: leave the fossil documentation as-is and expect that anyone actually
using nginx will have read the nginx documentation to properly integrate
the working example into their config if they are doing something more
complicated; or change the fossil documentation to include the ^~
and make it look less obvious to anyone not using nginx.
Either works; what is there currently is not incorrect.
f
--
Francis Dalyfran...@daoine.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On Tue, May 27, 2014 at 02:19:09PM -0600, Andy Bradford wrote: Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400: Hi there, Perhaps this should really be something like the following? th1 html base href='$baseurl/[httpize $current_page]' / /th1 This results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href='http://localhost:8080/doc%2Ftip%2Ffile%2B%2B.wiki' / The slash to %2F encoding there is wrong, unfortunately. If file.wiki is served as html and includes a relative link -- such as in img src=a.png, then that base href should have the browser requesting http://localhost:8080/a.png instead of the (probably intended) http://localhost:8080/doc/tip/a.png. HTML can be fiddly, even if you pretend that all browsers handle things correctly :-( f -- Francis Dalyfran...@daoine.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On Wed, May 28, 2014 at 9:28 AM, Francis Daly fran...@daoine.org wrote: Strictly, space is only encoded as + in the QUERY_STRING part of a URL. 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=... If we expand that to: /wiki/VisualC++ == /wiki/?name=VisualC++ then we have an ambiguity vis-a-vis the QUERY_STRING. i don't have an answer :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
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
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On Wed, May 28, 2014 at 7:51 PM, Warren Young war...@etr-usa.com wrote: 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 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 Ah, correct. The onus is on the one creating the link to do the escaping. Where's the problem? There is none - a Denkfehler[1] on my part. [1] = http://www.dict.cc/?s=denkfehler -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On 5/28/2014 11:58, Stephan Beal wrote: On Wed, May 28, 2014 at 7:51 PM, Warren Young war...@etr-usa.com mailto:war...@etr-usa.com wrote: I don't see that there is ambiguity here at all. Ah, correct. The onus is on the one creating the link to do the escaping. ...which does mean it is *partly* Fossil's problem, but only insofar as it creates links itself, as when generating HTML from Markdown and Wiki sources. In Markdown, if I give it the text [the foo page](foo++), it mustn't molest my + signs. If instead I refer to the foo++ Wiki article from another Wiki article and Fossil chooses to generate an HTML page containing a URL using query it must URL-escape the + signs (...?name=foo%2b%2b), knowing that Fossil (or the SCGI proxy) will be decoding them. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Warren Young wrote: On May 27, 2014, at 7:55 PM, Joel Bruickj...@joelface.com wrote: Richard Hipp wrote: I think that's an HTTP thing. In a URL, spaces are encoded as +. It's really an HTML form thing [1] that only applies to the query portion of the URL. In the path component, we technically should be percent-encoding spaces and leaving any instances of + alone, which would then allow you to reference such files normally. That's a much more involved fix that offers very little value, though. Just file this under the more you know.” Actually, I just came up with a use case where you want Fossil to handle + without URL-decoding it. If you have foo.md containing with something like this: ...but for more on that, see [the VC++ README](README-VC++.md). and you link to it with a doc URL, you want the generated HTML to link to README-VC++.md, not to “README-VC .md”. You can make it create the right link by replacing the + signs with %2b, but that makes foo.md harder to read in a text editor. One reason to use doc URLs in the first place is that you want to refer to documentation files you will ship as part of your distributed source code, so you don’t have to have their content in two places. You're right, of course. What I really meant was, Thankfully this isn't an important issue for me at the moment or I'd have to spend time fixing it. ;) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] FYI: doc URLs don't work with filenames that have + in their names
I had a file called README-Visual-C++.txt in one of my repositories and wanted to link to the tip version of it from an outside web page. I discovered the doc URL feature in Fossil, but it didn't work with that file. Apparently there's some kind of data sanitization going on here that turns the +'s into spaces. I say had because I just renamed it to README-Visual-Studio.txt and moved on. Perhaps someone wants to fix this in Fossil, though. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On Tue, May 27, 2014 at 3:43 PM, Warren Young war...@etr-usa.com wrote: I had a file called README-Visual-C++.txt in one of my repositories and wanted to link to the tip version of it from an outside web page. I discovered the doc URL feature in Fossil, but it didn't work with that file. Apparently there's some kind of data sanitization going on here that turns the +'s into spaces. I say had because I just renamed it to README-Visual-Studio.txt and moved on. Perhaps someone wants to fix this in Fossil, though. I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. If the filename really does contain + symbols, then the URL should have %2b for each plus. ex: http://localhost/doc/trunk/README-Visual-C%2b%2b.txt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400: I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. It certainly handles them correctly when given them, however, there may be a potential buglet in how it publishes the base URL. All of the skins for the header include the following: base href=$baseurl/$current_page / Which results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/file++.wiki; / So it appears that it doesn't preserve the encoding. Should it? Perhaps this should really be something like the following? th1 html base href='$baseurl/[httpize $current_page]' / /th1 This results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href='http://localhost:8080/doc%2Ftip%2Ffile%2B%2B.wiki' / Thanks, Andy -- TAI64 timestamp: 40005384f35f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Or, maybe $current_page should be HTTP-encoded instead of plaintext. On Tue, May 27, 2014 at 4:19 PM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400: I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. It certainly handles them correctly when given them, however, there may be a potential buglet in how it publishes the base URL. All of the skins for the header include the following: base href=$baseurl/$current_page / Which results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/file++.wiki; / So it appears that it doesn't preserve the encoding. Should it? Perhaps this should really be something like the following? th1 html base href='$baseurl/[httpize $current_page]' / /th1 This results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href='http://localhost:8080/doc%2Ftip%2Ffile%2B%2B.wiki' / Thanks, Andy -- TAI64 timestamp: 40005384f35f -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Candidate fix checked into trunk. On Tue, May 27, 2014 at 4:21 PM, Richard Hipp d...@sqlite.org wrote: Or, maybe $current_page should be HTTP-encoded instead of plaintext. On Tue, May 27, 2014 at 4:19 PM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400: I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. It certainly handles them correctly when given them, however, there may be a potential buglet in how it publishes the base URL. All of the skins for the header include the following: base href=$baseurl/$current_page / Which results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/file++.wiki; / So it appears that it doesn't preserve the encoding. Should it? Perhaps this should really be something like the following? th1 html base href='$baseurl/[httpize $current_page]' / /th1 This results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href='http://localhost:8080/doc%2Ftip%2Ffile%2B%2B.wiki' / Thanks, Andy -- TAI64 timestamp: 40005384f35f -- D. Richard Hipp d...@sqlite.org -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Hello, on Tuesday 27 May 2014 at 15:46, Richard Hipp wrote: On Tue, May 27, 2014 at 3:43 PM, Warren Young war...@etr-usa.com wrote: I had a file called README-Visual-C++.txt in one of my repositories and wanted to link to the tip version of it from an outside web page. I discovered the doc URL feature in Fossil, but it didn't work with that file. Apparently there's some kind of data sanitization going on here that turns the +'s into spaces. I say had because I just renamed it to README-Visual-Studio.txt and moved on. Perhaps someone wants to fix this in Fossil, though. I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. If the filename really does contain + symbols, then the URL should have %2b for each plus. ex: http://localhost/doc/trunk/README-Visual-C%2b%2b.txt In mohawk (tiny) webserver project we encountered the same kind of problem, and discovered in the process that major webserver (like apache, nginx and lighttpd, though I don't remember exactly which ones) fall back on not decoding '+' when providing files from disk. I can understand how one could see value in following the most common behavior even when it's technically not the right thing to do. Hoping this helps, Natacha Porté pgpISegVxdCcY.pgp Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 13:46, Richard Hipp wrote: If the filename really does contain + symbols, then the URL should have %2b for each plus. Sorry, I should have mentioned that I did try that. This is with the nginx-proxied configuration that I posted here about on Sunday. I suspect nginx is translating the %2b to + before sending the URL on per http://forum.nginx.org/read.php?2,75231,175761#msg-175761 According to that forum post, nginx only does this when the proxy URL has a trailing slash, but I need that to avoid the redirect issue I mentioned in that Sunday post. Here's the headers for one iteration of the redirect loop: Request by Firefox: GET /code/timeline HTTP/1.1 Host: xx.org Cookie: fossil-blablabla X-Other-Headers: squished Response from Fossil: HTTP/1.1 302 Moved Temporarily Server: nginx/1.4.6 (Ubuntu) Date: Tue, 27 May 2014 22:38:10 GMT Content-Type: text/html; charset=utf-8 Content-Length: 96 Connection: keep-alive Location: http://x.org/code/timeline X-Frame-Options: SAMEORIGIN Cache-Control: no-cache Content-Encoding: gzip Vary: Accept-Encoding As you can see, the 302 sends us right back to the page we requested, so it loops until the browser hits its redirect limit. It seems I can either have URL encoding passed unchanged, or I can have the proxy actually work. I can't have both at once. Rather than make Fossil tolerate unescaped + in URLs as Natacha noticed that the the mainstream web servers do, I'd rather figure out why the redirect loop happens and fix that. I'm willing to test tip-o-trunk versions to help resolve this. I've got this Fossil server running on an in-development site, which is why I've redacted the URLs above. I probably have a month or so to play with it before I'm going to publish the URL. Until then, I can break it any time I want and leave it broken for long periods. Incidentally, I'm bothering with nginx proxying because the SCGI method seems to have broken in 1.28. It was working fine on my site with 1.27 from the Ubuntu repository until I upgraded to 1.28 by building from source. (I wanted the /tree feature.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 14:37, Richard Hipp wrote: Candidate fix checked into trunk. I just installed [5d4400400a] and it still doesn't work, regardless of %2b or not %2b. (That *was* the query, quoth Hamlet after all.) I get a Document Not Found page back from Fossil, with the body section being No such document: test .txt Yes, just one space, despite the document being called test++.txt. Odd. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com wrote: Incidentally, I'm bothering with nginx proxying because the SCGI method seems to have broken in 1.28. It was working fine on my site with 1.27 from the Ubuntu repository until I upgraded to 1.28 by building from source. (I wanted the /tree feature.) This should work in trunk or when 1.29 comes out, as Richard fixed it post 1.28. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 17:10, Joe Prostko wrote:
On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
Incidentally, I'm bothering with nginx proxying because the SCGI
method seems to have broken in 1.28. It was working fine on my site
with 1.27 from the Ubuntu repository until I upgraded to 1.28 by
building from source. (I wanted the /tree feature.)
This should work in trunk or when 1.29 comes out, as Richard fixed it
post 1.28.
Confirmed. I'm back on SCGI now. Thanks!
(And yes, /code/doc/trunk/test%2b%2b.txt pulls my test file now, even
with nginx in the way.)
I'm still willing to help debug the nginx HTTP proxy case, though.
While on the topic, the SCGI discussion on this page:
http://www.fossil-scm.org/index.html/doc/tip/www/server.wiki
would be better with two changes:
1. You don't need to do regex matching on the URL here. This does the
same thing more efficiently and more clearly:
location /demo_project/ {
nginx does prefix matching by default. Using regex matching (~) just to
pin the match to the start of the path with ^ adds nothing.
(Ref: http://nginx.org/en/docs/http/ngx_http_core_module.html#location)
2. In addition to adding --scgi, the page should also recommend that you
add --localhost. If you're going to proxy fossil server via
nginx+SCGI, you probably don't want to have a public listener that lets
someone bypass nginx.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Is the documentation better now?
http://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki#scgi
Thanks for testing out SCGI for us.
On Tue, May 27, 2014 at 7:31 PM, Warren Young war...@etr-usa.com wrote:
On 5/27/2014 17:10, Joe Prostko wrote:
On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
Incidentally, I'm bothering with nginx proxying because the SCGI
method seems to have broken in 1.28. It was working fine on my site
with 1.27 from the Ubuntu repository until I upgraded to 1.28 by
building from source. (I wanted the /tree feature.)
This should work in trunk or when 1.29 comes out, as Richard fixed it
post 1.28.
Confirmed. I'm back on SCGI now. Thanks!
(And yes, /code/doc/trunk/test%2b%2b.txt pulls my test file now, even with
nginx in the way.)
I'm still willing to help debug the nginx HTTP proxy case, though.
While on the topic, the SCGI discussion on this page:
http://www.fossil-scm.org/index.html/doc/tip/www/server.wiki
would be better with two changes:
1. You don't need to do regex matching on the URL here. This does the
same thing more efficiently and more clearly:
location /demo_project/ {
nginx does prefix matching by default. Using regex matching (~) just to
pin the match to the start of the path with ^ adds nothing.
(Ref: http://nginx.org/en/docs/http/ngx_http_core_module.html#location)
2. In addition to adding --scgi, the page should also recommend that you
add --localhost. If you're going to proxy fossil server via nginx+SCGI,
you probably don't want to have a public listener that lets someone bypass
nginx.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 17:41, Richard Hipp wrote: Is the documentation better now? Yes, thanks! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 17:48, Warren Young wrote: On 5/27/2014 17:41, Richard Hipp wrote: Is the documentation better now? Yes, thanks! Ooops, grammar bug: Add one might want... Do you mean Additionally, ...? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Thus said Richard Hipp on Tue, 27 May 2014 16:37:01 -0400: Candidate fix checked into trunk. Works here, and much nicer than what I suggested: Before: $ printf 'GET /doc/tip/test/test-page%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/test/test-page++.wiki; / After: $ printf 'GET /doc/tip/test/test-page%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/test/test-page%2B%2B.wiki; / Andy -- TAI64 timestamp: 400053852743 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
On Tue, May 27, 2014 at 11:31 PM, Warren Young war...@etr-usa.com wrote:
On 5/27/2014 17:10, Joe Prostko wrote:
On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
Incidentally, I'm bothering with nginx proxying because the SCGI
method seems to have broken in 1.28. It was working fine on my site
with 1.27 from the Ubuntu repository until I upgraded to 1.28 by
building from source. (I wanted the /tree feature.)
This should work in trunk or when 1.29 comes out, as Richard fixed it
post 1.28.
Confirmed. I'm back on SCGI now. Thanks!
No problem! I reported it some time back, and Richard committed the fix.
1. You don't need to do regex matching on the URL here. This does the same
thing more efficiently and more clearly:
location /demo_project/ {
nginx does prefix matching by default. Using regex matching (~) just to pin
the match to the start of the path with ^ adds nothing.
I always write this as:
location ~ ^/demo_project {
myself. That way, it's a case-sensitive search where I don't have to
worry about the trailing slash, and it stops searching once it finds
/demo_project. I could be mistaken though, but I thought the way you
suggested wouldn't be as flexible.
I guess I'd have to test it to be sure, as anything resembling regex
is kind of like black magic to me. ;)
- joe
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Richard Hipp wrote: I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. If the filename really does contain + symbols, then the URL should have %2b for each plus. ex: http://localhost/doc/trunk/README-Visual-C%2b%2b.txt It's really an HTML form thing [1] that only applies to the query portion of the URL. In the path component, we technically should be percent-encoding spaces and leaving any instances of + alone, which would then allow you to reference such files normally. That's a much more involved fix that offers very little value, though. Just file this under the more you know. [1] http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FYI: doc URLs don't work with filenames that have + in their names
Thus said Joel Bruick on Tue, 27 May 2014 21:55:06 -0400: It's really an HTML form thing [1] that only applies to the query portion of the URL. In the path component, we technically should be percent-encoding spaces and leaving any instances of + alone, which would then allow you to reference such files normally. Does the specification for URIs apply in this case? http://tools.ietf.org/html/rfc3986 If I read the RFC correctly, it seems that 0x2b (+) is allowed in a URI as a sub-delim character unless it conflicts: sub-delims= ! / $ / / ' / ( / ) / * / + / , / ; / = Section 2.2: ... If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed. ... The purpose of reserved characters is to provide a set of delimiting characters that are distinguishable from other data within a URI. URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Not sure if this helps ore muddies the implementation. :-) Andy -- TAI64 timestamp: 4000538555eb ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
