Blag | Entry

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.