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/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx