or am I just going to have to hand-write a bunch of links in www/server.wiki to www/server/os/frontend.md?

A possibly useful tip: when i have a long list of links or JSON data which i want to reconstruct into something else, but don't have an associated page to run the JS in, i'll often pack the data into a JS file, mutilate the data there, outputting its new form with console.debug(), paste that script into the browser's dev tools, and (finally) copy the output for use elsewhere. It's not pretty, but it works. (Yes, i'm aware that server-side JS is a thing nowadays, but i have personal hangups against using node.js and its brethren.)

I actually considered writing a Tcl script and tying it into the build system, much the same way as www/mkindex.tcl works, but then I saw that there's no "#include" feature in Fossil Wiki, either, so I'd have to generate the entire www/server.wiki page from it.

We're shaving yaks here....

My initial thought is that if you want to use JS, you need to go full-on HTML too. Instead of a markdown or wiki document, use the embedded-HTML style:

<div class='fossil-doc' data-title='TITLE'>
  ... document text here ...
</div>

I'm open to extending this mechanism with a new data-nonce=NAME parameter which causes Fossil to scan the content of the document and substitute all occurrences of the string "NAME" with the current nonce. For instance:

<div class='fossil-doc' data-title='TITLE' data-nonce='NONCEHERE'>
  blah blah blah
  <script nonce='NONCEHERE'>
    ...
  </script>
</div>

This would require changing the document suffix from ".wiki" or ".md" to ".html". But if we are talking about "server.wiki", I'm ok with that.

I didn't even know that was possible. Thanks.

But as for changing the name of the doc, isn't that one of the most linked-to pages on the site from outside?

Solution: set up a Fossil alias (Admin → URL Aliases) for it, pointing at the new doc location. Will that forward named anchor and ID references, though?

I've just discovered the index page support in /doc. How do you like www/server/index.html?

I won't make that change yet; I said I'll keep my hands off the tree for a while, and that I shall. Really. I'm just floating the trial balloon for now.

But as for changing the name of the doc, isn't that one of the most linked-to pages on the site from outside?

Hmm...

Ok, what if we enhance /doc so that for documents that consist of a exactly one line of text of the form

    redirect: RELATIVE-PATH

where RELATIVE-PATH is the relative pathname of a different embedded document on the same server, that it does a redirect? Or maybe instead of a redirect, it just loads the alternative document directly and doesn't even tell the client?

This behavior would apply to /doc only - not to /file or /artifact or /raw - and only if the /doc page omits the mimetype= query parameter.

I'm struggling to see the value. Fossil URL aliases sync, so we've already got the basic ability we need here.

Also, I've since verified that named anchor and ID references do work through Fossil aliases.

The only argument I can see in favor of your plan is that Fossil URL aliases don't participate in the check-in naming feature of /doc. That is, if you want /doc/trunk/foo.md and /doc/ckout/foo.md to point at the same /doc/*/foo/index.html file, with each pointing at the corresponding named version, Fossil URL aliases don't currently have the wildcard support needed to allow this.

So, if I can be greedy, what I'd like is regexes with group references support in URL aliases: /doc/(\w+)/foo.md → /doc/$1/foo/index.html.

That's PCRE syntax, which is something I'd also like, but if it has to be POSIX ERE, I can live with that. But please not BRE. :)

I've thought some more about this, and I think the current URL Aliases feature will suffice, since we can probably get by with only the /trunk alias. My argument above that server.wiki is widely linked-to only applies to the trunk version, so simple static aliases should suffice.

On the subject of query parameters, does Fossil understand any other query parameters when it is serving embedded docs, or is mimetype the only one?

It also accepts "name" as an alternative to the common method of naming /doc pages. These are equivalent:

    http://fossil-scm.org/fossil/doc?name=trunk/www/server.wiki
    http://fossil-scm.org/fossil/doc/trunk/www/server.wiki

There's also a "raw" parameter that Fossil only pays attention to in conjunction with the default-disabled TH1 docs feature.

I've just checked in a new feature on the server-docs branch to add support for nonce="$NONCE" substitution, working off the pattern of the pre-existing href="$ROOT" embedded documentation feature.

This new feature is on the branch because it's necessary for the new www/server/index.html file, which will shortly be getting a new <script> block, as previously discussed.

This check-in also documents $ROOT and TH1 docs for the first time, though the latter is really thin. We could use some examples. Surely someone is using TH1 docs under battle conditions?

(Apparently <script> isn't blocked the same way by our current CSP. Maybe it should be, now that we have a way around the problem that blocking it would create?)

The initial JS tutorial selector is working and checked in on the server-docs branch, but it doesn't work on fossil-scm.org yet because it requires this new nonce feature. I see several paths forward:

1. Temporarily disable the new JS code and remove the <noscript> wrapper around the old static <table> code, so people can at least play with the improved table.

2. Cherrypick my nonce feature into trunk and get it deployed onto fossil-scm.org.

3. Do all testing locally; if you want to see the new work, you need to be running the branch's version of Fossil locally.

Apparently <script> isn't blocked the same way by our current CSP.

Sorry, I meant <style>.

I went ahead and added a nonce attribute to the one in server/index.html, but I didn't look for uses of <style> elsewhere, so I don't know the impact of changing the CSP to disallow <style> without a nonce attribute.

I made some edits to that check-in.

And meanwhile, I'm a little concerned about security of this. It is possible for a project to have multiple security domains. Hoster A and hoster B (two different people) might both be hosting the same repository and syncing with each other (not necessarily directly) but have a different set of users. The new mechanism effectively allows anyone with login privileges to A to be able to inject arbitrary JS on B's website.

I need to think about that a little further. At the very least, there seems to be a need for a default-off option to enable the nonce="$NONCE" mechanism. Another option, is only all NONCE substitution if the document is checked in by or approved by one of a list of trusted users. (Approved-by would be a new tag.)

I've just coincidentally stumbled across the ./configure --th1-docs feature, which appears to allow TH1 expressions inside curly braces within embedded docs.

It's default-disabled, though, and it looks like this plain-HTML option will suffice, so I don't think this feature request is going anywhere. I'm posting this in case someone else digs this thread up later and wants the option.