Error_page directive, how does context affect error handling behavior?

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?

Thank you in advance for any help.
Gregory

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

Hi Max,

Thank you for your answer. May I suggest that explanation enters the
wiki
in the error_page directive section?

Gregory

Hello!

On Mon, Feb 27, 2012 at 03:19:38PM +0100, Grégory Pakosz wrote:

Hi Max,

Thank you for your answer. May I suggest that explanation enters the wiki
in the error_page directive section?

http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page

: These directives are inherited from the previous level if and
: only if there are no error_page directives on the current level.

Maxim D.

27 февраля 2012, 20:07 от Grégory Pakosz : > > > > > > Thank you for
your answer. May I suggest that explanation enters the wiki > > > in the
error_page directive section? > > > >
http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page > > >

: These directives are inherited from the previous level if and > > :
only if there are no error_page directives on the current level. > > > >
Fair enough! > > I’ll refer to the doc more often then :slight_smile: > > Thank you
for the help You’re welcome. Maxim is right, this is documented, but the
implicit reset is not mentioned, so I’ve updated the wiki to make that
clear: http://wiki.nginx.org/HttpCoreModule#error_page Max

Fair enough!

I’ll refer to the doc more often then :slight_smile:

Thank you for the help
Gregory

Hello!

On Tue, Feb 28, 2012 at 07:53:23AM +0400, Max wrote:

27 февраля 2012, 20:07 от Grégory Pakosz : > > > > > > Thank you for your
answer. May I suggest that explanation enters the wiki > > > in the error_page
directive section? > > > >
http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page > > > > : These
directives are inherited from the previous level if and > > : only if there are no
error_page directives on the current level. > > > > Fair enough! > > I’ll refer to
the doc more often then :slight_smile: > > Thank you for the help You’re welcome. Maxim is
right, this is documented, but the implicit reset is not mentioned, so I’ve
updated the wiki to make that clear:
http://wiki.nginx.org/HttpCoreModule#error_page Max

There is no “implicit reset”, it’s just a result of no
inheritance. I don’t think that such a detailed explanation of
how inheritance work is a good idea in context of error_page
directive documentation.

If you think this often causes serious misunderstanding, you may
want to place the detail description somewhere at
http://wiki.nginx.org/Pitfalls, metioning various array-type
directives which follow the same logic.

Maxim D.

p.s. You may want to avoid posting html to the list, especially
keeping in mind that text parts of your html messages are hardly
readable due to no line breaks.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs