Serving default error pages with 'proxy_intercept_errors on'

[Maxim Dounin]

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.

> The question is whether this behavior is an accident and may change in
> a future version, or if it's an acceptable way of intercepting errors
> without providing custom error pages?

I wouldn't recommend relaying on this.  Current behaviour of 
"return", which effectively uses previous error code set, is 
somewhat questionable, and may change in the future.

-- 
Maxim Dounin
http://nginx.org/