On Sat, Dec 28, 2013 at 7:19 AM, Maxim Dounin <mdounin@mdounin.ru> 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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx