error_page directive, how does context affect error handling behavior?

[Max]

 26 февраля 2012, 22:49 от Grégory Pakosz : > Hello, > > I'm using nginx 1.1.14 on Debian Squeeze. > > In /etc/nginx.conf I wrote: > error_page 404 http://google.com; > > That error_page directive is written in the http context. > > So far so good, when I visit http://mydomain.com/foo.txt and foo.txt > doesn't exist in root's folder, I'm getting redirected to http://google.com as > per the 404 error handling. > > However, if in my server context, inside /etc/sites-available/default, I > write: > error_page 418 http://nginx.org; > > Then 404 error handling from http's context doesn't work anymore. When I > visit http://mydomain.com/foo.txt I'm not redirected to http://google.com as > before but I see nginx's default 404 error page "404 Not found". > > here is my nginx.conf: http://pastebin.com/5nffYFvK > and my default site conf: http://pastebin.com/CYcEFnwx > > Is there something I overlooked about nginx's error_page directive? The error_page directives are inherited if and only if there is absolutely NO error_page directive on the current level. Moreover, whenever you use the error_page directive you are doing two things: 1) explicitly setting error pages for the specified error codes 2) implicitly resetting error pages for all the other error codes that are not explicitly set on the current level to their default values So your "error_page 418 http://nginx.org;" directive not only set the error page for error code 418, but also reset the error pages for error code 404 and all the other error codes to their default values. Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20120227/5c8034a9/attachment.html>