Re: [fossil-users] Markdown wiki relative links
Sure, a name like /wiki/a/b could be interpreted as /wiki?name=a/b, but it would still break relative paths. It's not enough for Fossil to understand that the / in a/b isn't a path separator; the browser would need to understand that as well. Linking to (c) would either go to /wiki/a/c or /c, but not /wiki/c. On Thu, Jul 5, 2018, 02:30 Dominique Devienne wrote: > On Wed, Jul 4, 2018 at 11:37 PM Stephan Beal > wrote: > >> i don't _think_ that you can use %2f in a path component and have it >> apply different semantics than a slash. How would software know to >> differentiate between the two? That would be similar to expecting a local >> file name of a\/b to work. (If it did work, it would cause no end of >> confusion.) >> > > Sure. The slash(es) would be part of the URL. > But it's the job of the "URL router" to figure it out. > > There's likely a known prefix for wiki pages, so the URL's subpart after > that prefix > can be interpreted as a "name", as is. > > It's definitely not "usual" to route a URL that way, but it certainly > possible IMHO. --DD > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ 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 wiki relative links
On Wed, Jul 4, 2018 at 11:37 PM Stephan Beal wrote: > i don't _think_ that you can use %2f in a path component and have it apply > different semantics than a slash. How would software know to differentiate > between the two? That would be similar to expecting a local file name of > a\/b to work. (If it did work, it would cause no end of confusion.) > Sure. The slash(es) would be part of the URL. But it's the job of the "URL router" to figure it out. There's likely a known prefix for wiki pages, so the URL's subpart after that prefix can be interpreted as a "name", as is. It's definitely not "usual" to route a URL that way, but it certainly possible IMHO. --DD ___ 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 wiki relative links
On 07/04/18 16:37, Stephan Beal wrote: i don't _think_ that you can use %2f in a path component and have it apply different semantics than a slash. How would software know to differentiate between the two? That would be similar to expecting a local file name of a\/b to work. (If it did work, it would cause no end of confusion.) Fossil already does apply different semantics. It's simple, but not what you're thinking: As far as I can tell, Fossil rejects URLs containing %xx in the path. Sounds like a good way to avoid people sneaking metacharacters past security filters. Wouldn't want %2e%2e%2f to come up as ../ allowing you to see files outside of the document root! -- Andy Goth | ___ 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 wiki relative links
i don't _think_ that you can use %2f in a path component and have it apply different semantics than a slash. How would software know to differentiate between the two? That would be similar to expecting a local file name of a\/b to work. (If it did work, it would cause no end of confusion.) - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 23:26 Andy Goth wrote: > On 07/04/18 16:01, Stephan Beal wrote: > > Fwiw, a few years back i created a patch which caused generated wiki > > links to always emit wiki/x rather than name=x, but it was pointed out > > to me that wiki/x doesn't work when x contains a slash, which is a valid > > wiki page name character. Thus the portable approach is to use name=x. :/ > > Well, I totally forgot slashes could be in page names. What about %2f? > > -- > Andy Goth | > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ 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 wiki relative links
On 07/04/18 16:01, Stephan Beal wrote: Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/ Well, I totally forgot slashes could be in page names. What about %2f? -- Andy Goth | ___ 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 wiki relative links
Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/ - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 22:54 Andy Goth wrote: > To create a link in the Markdown wiki, the syntax is [like this](url). > That's all well and good, but what precisely does url need to be for one > page to link to another? In writing embedded documentation, I've gotten > used to relative paths, so in order to link /doc/trunk/doc/foo.md to > /doc/trunk/doc/bar.md, I write (bar.md). > > However, with the wiki, there's an issue. Most (if not all) of the > links into the wiki use the ...?name=page syntax rather than the > theoretically equivalent .../page syntax. This throws off relative > paths entirely. Relative links between wiki pages will be different > depending on which "equivalent" syntax was used to access the wiki. > > Suppose wiki page foo wants to link to wiki page bar. If foo was > accessed as wiki?name=foo, then it must link to (wiki?name=bar) or > (wiki/bar). But if foo was accessed as wiki/foo, it must link to (bar), > which it what I hoped would work all along. > > To make intra-wiki links work regardless of which syntax is used to > access the wiki, it appears it's necessary to use "absolute" (actually > relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar). > This is not something I've had to deal with (yet?) when doing embedded > documentation. > > My preference would be for Fossil to never send the name query parameter > to the user. If a name query parameter is received from the user, I > think maybe Fossil should not call the webpage function (other than > confirming that one exists) and instead immediately send a 301 Moved > Permanently back to the user to rewrite the URL to use /. > > Or maybe I'm missing something fundamental here. > > There's one other style of relative link I'll mention: (?name=bar). > This replaces the name query parameter. I don't think this would work > very well if linked from /wiki/foo. Also it gets even weirder when > clicking a link in the preview shown by wikiedit, since it takes the > user to the editor for the target page. But this last would still occur > should we replace all ?name= with /. To avoid that, the link would have > to be either (/wiki/bar) or (../wiki/bar), though of course that last > one combines the worst of all worlds. > > For now, I'll make sure all my wiki links are to /wiki/whatever. > > Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's > what Chiselapp uses. > > -- > Andy Goth | > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Markdown wiki relative links
To create a link in the Markdown wiki, the syntax is [like this](url). That's all well and good, but what precisely does url need to be for one page to link to another? In writing embedded documentation, I've gotten used to relative paths, so in order to link /doc/trunk/doc/foo.md to /doc/trunk/doc/bar.md, I write (bar.md). However, with the wiki, there's an issue. Most (if not all) of the links into the wiki use the ...?name=page syntax rather than the theoretically equivalent .../page syntax. This throws off relative paths entirely. Relative links between wiki pages will be different depending on which "equivalent" syntax was used to access the wiki. Suppose wiki page foo wants to link to wiki page bar. If foo was accessed as wiki?name=foo, then it must link to (wiki?name=bar) or (wiki/bar). But if foo was accessed as wiki/foo, it must link to (bar), which it what I hoped would work all along. To make intra-wiki links work regardless of which syntax is used to access the wiki, it appears it's necessary to use "absolute" (actually relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar). This is not something I've had to deal with (yet?) when doing embedded documentation. My preference would be for Fossil to never send the name query parameter to the user. If a name query parameter is received from the user, I think maybe Fossil should not call the webpage function (other than confirming that one exists) and instead immediately send a 301 Moved Permanently back to the user to rewrite the URL to use /. Or maybe I'm missing something fundamental here. There's one other style of relative link I'll mention: (?name=bar). This replaces the name query parameter. I don't think this would work very well if linked from /wiki/foo. Also it gets even weirder when clicking a link in the preview shown by wikiedit, since it takes the user to the editor for the target page. But this last would still occur should we replace all ?name= with /. To avoid that, the link would have to be either (/wiki/bar) or (../wiki/bar), though of course that last one combines the worst of all worlds. For now, I'll make sure all my wiki links are to /wiki/whatever. Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's what Chiselapp uses. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
