On Sat, Dec 28, 2013 at 7:19 AM, Maxim Dounin <[email protected]> wrote: > Hello! > > On Fri, Dec 27, 2013 at 03:47:51PM -0500, Maxim Khitrov wrote: > >> Hello, >> >> I'm running nginx v1.4.1 on OpenBSD 5.4 and I'd like to use >> 'proxy_intercept_errors on' directive without providing my own error >> pages. In other words, instead of forwarding page content from the >> backend server, just use the error pages that nginx generates by >> default. >> >> This isn't supported normally, however the following configuration >> seems to achieve the desired result (though you have to list the error >> codes explicitly): >> >> error_page 403 404 ... @error; >> location @error { return 444; } >> >> I didn't actually know what this would do until I tried it. I assume >> that when a matching error code is received from the backend server, >> nginx closes the proxy connection without reading the body and creates >> a new internal request to @error, which is immediately closed without >> a response. Thus, there is no body to send to the client, so it falls >> back to the default behavior. > > Not really. > > What you see works because currently "return <4xx>" doesn't > override error code previously set, thus for 404 error code > originally returned by a proxied server > > location @error { return 4xx; } > > is effectively equivalent to > > location @error { return 404; } > > which is documented to return "status code of the last occurred > error", see http://nginx.org/r/error_page.
I thought that the original error code is returned because I'm not using '=[response]' syntax in the error_page directive. You're saying that 'return' may, at some point in the future, change the original status code even though I'm not using 'error_page 403 404 = @error' (with the equal sign)? Is there any other way of getting nginx to return the default error pages in this situation? _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
