Internal marked 503 error page returns default 404

Hi,

I have the following configuration:

server {
    location = /unavailable.html {
        internal;
    }

    try_files $uri =503;

    error_page 503 /unavailable.html;
}

My goal is to have all existing files with the exception of
unavailable.html served with 200, and serving unavailable.html with
503 for anything else and itself.

The location is marked as internal because otherwise a direct request
for /unavailable.html would result in a 200. The expectation is that
on a direct request it would be deemed non-existent by try_files, so a
503 would be issued, and through an internal redirect unavailable.html
would eventually be served.

Requesting /unavailable.html, however, results in the default 404
served, which is, after all, consistent with the documentation, but is
not what one would expect it to do.

The exact same problem was stated in a Server Fault question in 2011,
but it was never answered
http://serverfault.com/questions/230433/nginx-error-page-and-internal-directives-not-working-as-expected

Can anyone please shed some light on this?

Thanks,
Ádám

On Sat, Aug 22, 2015 at 04:31:35AM +0200, dm Jo wrote:

Hi there,

My goal is to have all existing files with the exception of
unavailable.html served with 200, and serving unavailable.html with
503 for anything else and itself.

The location is marked as internal because otherwise a direct request
for /unavailable.html would result in a 200. The expectation is that
on a direct request it would be deemed non-existent by try_files, so a

“selecting the location to handle this request” happens before
try_files. So try_files doesn’t get to say whether it exists or not.

503 would be issued, and through an internal redirect unavailable.html
would eventually be served.

Requesting /unavailable.html, however, results in the default 404
served, which is, after all, consistent with the documentation, but is
not what one would expect it to do.

If the expectation is that the documentation is wrong, the expectation
is probably incorrect.

Can anyone please shed some light on this?

I would probably move unavailable.html out of the “default” document
root,
so that it cannot be accessed directly.

Then use a named location, so that a request for /unavailable.html is
the same as a request for /random_filename.html.

location @unavailable {
root /tmp;
try_files /unavailable.html =500;
}
try_files $uri =503;
error_page 503 @unavailable;

The try_files with the “location @” strikes me as inelegant, but seems
to be the quickest way to always serve a single named file. The =500
could be =503, depending on what output you want when your preferred
unavailable.html file is not accessible.

f

Francis D. [email protected]

Hi Francis,

Thank you for your response. After some further reading I think now I
get the processing cycle. I would rather not create a separate root
for one file, so I settled with the following:

location = /unavailable.html {
    return 503;
}

location @unavailable {
    try_files /unavailable.html =500;
}

try_files $uri =503;

error_page 503 @unavailable;

Thanks,
Ádám

Hi Adam,

Why not use @named location directly?

error_page 503 @unavailable;
location @unavailable {
alias /absolute/path/to/file;
}

Notice the path is not related to document root.

On Tue, Aug 25, 2015, 05:33 Joó Ádám [email protected] wrote:

Hi Francis,

Thank you for your response. After some further reading I think now I
get the processing cycle. I would rather not create a separate root
for one file, so I settled with the following:

location = /unavailable.html {
    return 503;
}

location @unavailable {
    try_files /unavailable.html =500;
}

try_files $uri =503;

error_page 503 @unavailable;

Thanks,
Ádám

On Tue, Aug 25, 2015 at 02:39:14AM +0000, ryd994 wrote:

Hi there,

Why not use @named location directly?

error_page 503 @unavailable;
location @unavailable {
alias /absolute/path/to/file;
}

the “alias” directive cannot be used inside the named location

f

Francis D. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs