404 Method Not Allowed when returning 500 error to POST request
jsdalton
nginx-forum at nginx.us
Fri Mar 25 23:02:25 MSK 2011
Hi there,
I have what I consider to be an excellent configuration for how I'm
handling error pages with nginx running as a load balancer reverse proxy
in front of Apache. In a nutshell, if the upstream apache webserver
returns an error (let's say a 500), nginx will first check for an error
page in the current server folder (/var/www/currentserver.com/500.html)
and then if no file is found there, it checks a "default" folder
(/var/www/default/500.html). This is accomplished via the following
configuration:
server {
root /var/www/someserver.com/;
error_page 404 = @not_found;
error_page 500 502 504 = @server_error;
error_page 503 = @maintenance;
location @not_found {
try_files /404.html /../default/404.html =404;
}
location @server_error {
try_files /500.html /../default/500.html =500;
}
location @maintenance {
try_files /503.html /../default/503.html =503;
}
}
This worked well for me during testing, however I recently ran into a
problem:
When Apache returns a 500 server error in a POST request, instead of
getting the 500 response and page I normally would with a GET, I get a
405 Not Allowed response. (The error page is correct when I trigger a
500 with a GET.)
As far as I can tell, what is happening is that try_files is preserving
the request method of the *main* request as opposed to trying to simply
GET the file for the purposes of returning an error. Since 500.html is
static content, it's basically trying to POST to static content, which I
have read does not work at present.
I'm trying to figure out how best to proceed. One thought is that this
is perhaps a bug? In a sub request I don't see how it makes sense for
nginx to preserve the original request...well, at least not in the case
of error pages. You are never going to POST to an error page, you are
only every going to retrieve one via GET. But perhaps I am combining
error_page, fallback locations, and try_files in an unconventional way
that it is not supported or otherwise ill advised.
The hack I will probably pursue is finding a way to catch the 405 errors
within these locations but I haven't found a workaround just yet.
Anyhow, any advice or guidance would be immensely appreciated. Thank you
very much.
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,185782,185782#msg-185782
More information about the nginx
mailing list