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
[fossil-users] '-R' not mentioned in 'help timeline'
Hello, in fossil version 1.29 [87130593e4], '-R' switch is not mentioned in 'fossil help timeline' (but works fine). If any more of this kind of issues come up, where shall I report them? (I guess right here on the list.) Michai ___ 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] '-R' not mentioned in 'help timeline'
On Wed, May 28, 2014 at 5:37 PM, Michai Ramakers m.ramak...@gmail.comwrote: in fossil version 1.29 [87130593e4], '-R' switch is not mentioned in 'fossil help timeline' (but works fine). IIRC only a relative minority of commands don't support -R. As a rule of thumb, anything which can work without a checkout supports (or should support) -R. i'll get it added to the timeline docs in a moment if someone hasn't beaten me to it already. If any more of this kind of issues come up, where shall I report them? (I guess right here on the list.) Right - the list is the best first stop. -- - 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] '-R' not mentioned in 'help timeline'
On 28 May 2014 18:02, Stephan Beal sgb...@googlemail.com wrote: On Wed, May 28, 2014 at 5:37 PM, Michai Ramakers m.ramak...@gmail.com wrote: in fossil version 1.29 [87130593e4], '-R' switch is not mentioned in 'fossil help timeline' (but works fine). IIRC only a relative minority of commands don't support -R. As a rule of thumb, anything which can work without a checkout supports (or should support) -R. i'll get it added to the timeline docs in a moment if someone hasn't beaten me to it already. ok, clear - I was pleasantly surprised. Thx for fix in advance. Michai ___ 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] Markdown
On 5/27/2014 22:58, Scott Robison wrote: The best I can come up with for a link to a wiki page (from another wiki page) is something like [Page](wiki?name=Page) which really seems kinda ugly You probably want this syntax: [Page][1] later, typically at end of doc... [1]: wiki?name=Page ___ 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] Running script on push
On Tue, May 27, 2014 at 8:34 AM, Abilio Marques amarq...@smartappsla.comwrote: I was looking for an easier path. My set of tests can be run from command line, and I really like shell scripting, so I was wondering, does fossil has a trigger mechanism (on commit / push) run this command? Do you see any utility on such an idea, or is just me? Launching hook processes from Fossil has been discussed several times over the last few years. The problem with doing so has to do with the different ways this is done on the various platforms. For the most part, the alternatives Fossil does support, RSS feed and pinging a server via an URL, have served well enough that no one has taken up the task of launching processes from Fossil. ___ 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] Server static files to load JSON APP
On Tue, May 27, 2014 at 5:00 PM, Petrica Clement Chiriac (Tica2) petrica_chir...@fluxinternet.ro wrote: Hi fossil-users, I have simple JS app (build with GWT) and these static files are in one folder ./jsout You can get the raw content of any file stored in Fossil. For example: http://fossil-scm.org/index.html/raw/src/export.c?name=tip In your case, the following should work: http://localhost:8080/index.html/raw/jsout/index.html?name=tip ___ 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] Markdown
On Wed, May 28, 2014 at 12:05 PM, Warren Young war...@etr-usa.com wrote: On 5/27/2014 22:58, Scott Robison wrote: The best I can come up with for a link to a wiki page (from another wiki page) is something like [Page](wiki?name=Page) which really seems kinda ugly You probably want this syntax: [Page][1] later, typically at end of doc... [1]: wiki?name=Page Thanks. I did realize I could use [Page](wiki/Page) which is better if I just want to do it inline. The footnote style is good to know as well. Still, I've read various things online about what markdown does fossil support and I've read something like vanilla markdown plus some form tables extension. It would be nice to have a very central place (like a wiki page on the fossil repo) that says Here is the definitive list of what markdown use can use on fossil. I'm beginning to think the only place that documentation exists is in the code (which is fine, no one owes me an explanation for free software). Is this the case? -- Scott Robison ___ 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] Server static files to load JSON APP
On Wed, May 28, 2014 at 2:23 PM, Ron Wilson ronw.m...@gmail.com wrote: On Tue, May 27, 2014 at 5:00 PM, Petrica Clement Chiriac (Tica2) petrica_chir...@fluxinternet.ro wrote: Hi fossil-users, I have simple JS app (build with GWT) and these static files are in one folder ./jsout You can get the raw content of any file stored in Fossil. Also see the following for an additional way: http://fossil-scm.org/index.html/doc/tip/www/embeddeddoc.wik i ___ 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] Server static files to load JSON APP
Thanks Ron,
Now I use nginx with conf like this:
server {
listen 8081;
server_name localhost;
location ~ ^/(gwt)/ {
rootC:/static/gwt;
expires 30d;
}
location / {
proxy_pass http://localhost:8080;
}
}
And fossil is started with:
fossil server --baseurl http://localhost:8081/; repo.db
... and is working nice.
My content is here:
http://localhost:8081/gwt/XXX
and JSON calls to http://localhost:8081/json/YYY
GWT dev mode is started with:
-noserver
-startupUrl
And I can run and debug in Eclipse. (But this is GWT specific)
I will check also:
http://fossil-scm.org/index.html/doc/tip/www/embeddeddoc.wiki
Thanks,
Petrica
Also see the following for an additional way:
http://fossil-scm.org/index.html/doc/tip/www/embeddeddoc.wiki
___
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] Markdown
On May 28, 2014 2:31 PM, Warren Young war...@etr-usa.com wrote:
{deleted stuff}
The attached Fossil repo also contains a copy of the official Markdown
documentation. It was included in the test suite, so I linked to it from
the repo's wiki, rather than remove it.
Thanks very much for the effort!
___
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
