The tricky part of this app is trying to figure out a lighttpd equivalent for this nginx config snippet:

location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
    try_files $uri $uri/ /index.html;
}

The interesting part of that config is the try_files $uri $uri/ /index.html; statement. That tells the nginx server to:

• look for a file on disk matching the requested path and serve it if present
• look for a directory on disk matching the requested path and serve it if present
• if no file found on disk, return the index.html root document

Before diving into the lighttpd config side, I made the tool canonically redirect to its toolforge.org name. This will simplify things a bit in the lighttpd config. This can be done with webservice --backend=kubernetes --canonical php7.3 start. To make this easier to preserve, I created a $HOME/service.template file:

backend: kubernetes
type: php7.3
canonical: true

With that file created, we can just use webservice start and backend, type, and canonical flags will all be picked up from the template file.

The lighttpd url.rewrite-if-not-file directive is a close match for nginx's try_files. Let's try using that in a $HOME/.lighttpd.conf to do the mappings:

# Look for files on disk and if not found return our index
url.rewrite-if-not-file = (
    "(.*)" => "/index.html",
)

• legacy url: https://tools.wmflabs.org/moedata/album/2ABAeQdTwWlZZj4cW2zOWX
  • 307 redirect to https://moedata.toolforge.org/album/2ABAeQdTwWlZZj4cW2zOWX because of --canonical setting
• url: https://moedata.toolforge.org/album/2ABAeQdTwWlZZj4cW2zOWX
  • No $HOME/public_html/album/2ABAeQdTwWlZZj4cW2zOWX file or directory is found on disk, so $HOME/public_html/index.html is returned

I think this is working as expected at this point?

Here are a few notes/suggestions about other things I see the tool doing:

• https://moedata.toolforge.org/ returns a page saying "404 Mobeus not found!". It would be nice if instead the user was given a page with some basic info about the tool and either usage instructions or a link to some wiki page with instructions.
• Two content-security-policy reports are generated by the tool for fetching resources that are outside of the Wikimedia hosting environment:
  • https://cors-anywhere.herokuapp.com/https://tatsumo.pythonanywhere.com/api/album/2ABAeQdTwWlZZj4cW2zOWX
    • This is a double remote request in reality. First to https://cors-anywhere.herokuapp.com/ which is a proxy for adding CORS headers to anything, and then to https://tatsumo.pythonanywhere.com/api/album/2ABAeQdTwWlZZj4cW2zOWX which seems to be the main external API that the tool is automating use of
  • https://i.scdn.co/image/ab67616d0000b27373dc2eca0656689869d88ae9
    • This is an image URL returned by the tatsumo API for the album cover art

Eventually T130748: Add Content-Security-Policy header enforcing 3rd party web interaction restrictions to proxy responses may be changed from report-only mode to enforcement mode and then these requests will break. As these interactions are core to the tool's functionality, adding a reverse proxy with a restrictive allow list for proxied URLs to the tool itself is probably the "best" way to present the desired content without exposing the user to direct interaction with 3rd party hosting and potential tracking. This could be done with a PHP script to do the proxying.