[fossil-users] Markdown wiki relative links

[Andy Goth]

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.

[Stephan Beal]

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.

Post by Andy Goth
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 | <andrew.m.goth/at/gmail/dot/com>
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Andy Goth]

Post by Stephan Beal
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?

[Stephan Beal]

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.

Post by Andy Goth

Post by Stephan Beal
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 | <andrew.m.goth/at/gmail/dot/com>
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Andy Goth]

Post by Stephan Beal
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!

[Dominique Devienne]

Post by Stephan Beal
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

[Andy Goth]

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.

Post by Dominique Devienne

Post by Stephan Beal
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users