A few days later, and some aggravation regarding spawn-fcgi, nginx and the aptly named libwtfcgi fast-cgi adaptor of Wt, the page is finally live for real. Most examples for wtfcgi Wt with fcgi assume that the “application” is deployed on some sub-URL (such as http://example.com/app.wt/foo), rather than in the root (i.e., http://example.com/foo). This means that some of the largely undocumented fastcgi_params need to be adjusted.
The nginx config that ended up working for me - with the “application” deployed in the root - is:
location /dl {
try_files $uri @appdl;
}
location / {
try_files $uri @app;
}
location @app {
fastcgi_pass unix:/srv/fcgi/wt-home.socket-1;
fastcgi_param SCRIPT_NAME "/";
fastcgi_param PATH_INFO $uri;
# other fastcgi_param as in the examples/default configs.
}
location @appdl {
fastcgi_pass unix:/srv/fcgi/wt-home.socket-1;
fastcgi_param SCRIPT_NAME @uri;
fastcgi_param PATH_INFO "";
# other fastcgi_param as in the examples/default configs.
}
With this, static files are served by nginx itself, rather than having them take the detour via Wt. The @appdl-block deals with dynamic downloads under the /dl-path, which refer to things served by Wt via WServer::addResource().
There’s still a bunch of problems with the page (at least according to the W3 validators), and there’s also a bunch of things I’d like to do. But since this isn’t the 1990:s anymore, I’ll refrain from putting “under-construction” icons everywhere.