@dvl find myself wondering if you could do similar with `try_files` since you're serving the content of the "marker" file.

[jamesoff@mastodon.jamesoff.net]

@dvl find myself wondering if you could do similar with `try_files` since you're serving the content of the "marker" file. Don't think it would be any real benefit over what you have already (especially as it works) other than a shorter config file Might have a go with it later if I get a moment.

[jamesoff@mastodon.jamesoff.net]

@dvl ah in fact while idly looking at the docs for it, one of their examples has a maintenance file as the first path to try (then other files on disk based on the URI) then a proxy location. Have a look at the "Mongrel" example at https://nginx.org/en/docs/http/ngx_http_core_module.html#try_files - you'd just rename your current `location /` block to `location at-proxy` (if I type an @ it tries to mention someone ;), and use that as the last item in try_files.

[dvl@bsd.network]

@jamesoff

Reading that, and combining with my two-stage approach:

location / {
try_files /system/maintenance.html
/system/site-wide-maintenance.html
$uri $uri/index.html $uri.html
@mongrel;
}

[jamesoff@mastodon.jamesoff.net]

@dvl yeah something like that - you might not want the line with the $url stuff on it as from your blog post I think everything is served from your upstream? The $url line makes nginx look on the disk (under the "root") for the requested path and serve it if it exists. No harm if none of the paths will exist, but clear if you remove it.

I'd use a name like "proxy" instead of "mongrel" for the at-entry to make it clear what it's for (since "mongrel" is the name of an example app in the docs)