"error_page"& "return" bug?

Hello,

It appears that the error_page directive is ignored when a status code
is returned in the server context. (running v1.0.12 Stable).

Server {

listen etc

error_page 503 /error_docs/custom503.html;
return 503
location /error_docs {
internal;
alias /server/path/to/folder;
}


}

Will always return the Nginx default 503 page. Same applies to all
status codes.

When the status code is returned within a location block, the custom
page is shown as expected …

Server {

listen etc

error_page 503 /error_docs/custom503.html;
location / {
return 503;
}
location /error_docs {
internal;
alias /server/path/to/folder;
}


}

Hello!

On Sun, Feb 19, 2012 at 01:22:34PM +0300, Nginx U. wrote:

return 503
location /error_docs {
internal;
alias /server/path/to/folder;
}


}

Will always return the Nginx default 503 page. Same applies to all status codes.

It’s not ignored, but returning error unconditionally in the
server context also prevents error_page processing from
working, as the “return 503” is again executed after error_page
internal redirect. That is, something like this happens:

  1. Request comes for “/something”.
  2. Server rewrites generate 503.
  3. Due to error_page set the request is internally redirected to
    /error_docs/custom503.html.
  4. Server rewrites again generate 503.
  5. As we’ve already did error_page redirection, nginx ignores
    error_page set and returns internal error page.

}
location /error_docs {
internal;
alias /server/path/to/folder;
}


}

This doesn’t “return 503” for error_page processing, and hence it
works ok.

Another possible aproach is to use named location in error_page.
It won’t re-execute server rewrites (that is, rewrite module
directives, including the “return” directive, specified at server
level) and will work as well.

Maxim D.

On 19 February 2012 15:03, Maxim D. [email protected] wrote:

  1. Server rewrites again generate 503.
  2. As we’ve already did error_page redirection, nginx ignores
    error_page set and returns internal error page.

This then is the “bug”.
It SHOULD now return “/error_docs/custom503.html” with a 503 status
code.
I.E., work as it does when the error is issued within a location
context since once a user has set error_page, they would most likely
expect a matching status return to deliver what was set.

I assume there must be some technical road block but you guys are
supposed to be geniuses :slight_smile:

Can’t wait for the solution!!

On 19 February 2012 15:03, Maxim D. [email protected] wrote:

Another possible aproach is to use named location in error_page.
It won’t re-execute server rewrites (that is, rewrite module
directives, including the “return” directive, specified at server
level) and will work as well.

Unfortunately, this doesn’t appear to work as expected either

Server {
# listen etc

   error_page 503 = @sitedown;
   return 503
   location @sitedown {
           root /server/path/to/folder;
           # Don't you wish try_files could accept a single 

parameter?
try_files $uri /custom503.html;
}

   ...

}

Hello!

On Sun, Feb 19, 2012 at 03:23:58PM +0300, Nginx U. wrote:

/error_docs/custom503.html.
4. Server rewrites again generate 503.
5. As we’ve already did error_page redirection, nginx ignores
error_page set and returns internal error page.

This then is the “bug”.
It SHOULD now return “/error_docs/custom503.html” with a 503 status code.
I.E., work as it does when the error is issued within a location
context since once a user has set error_page, they would most likely
expect a matching status return to deliver what was set.

This is not a bug. You instructed nginx to generate 503 on each
request which hits server rewrite phase, and it does what you
said.

Maxim D.

On 19 February 2012 15:45, Nginx U. [email protected] wrote:


}
PS.

In any case, it would not be an ideal solution even if it did work as
it would return a “200” status code with the custom file.

So getting things to work as with the location option is probably best.

In the interim, I have managed to get it to work by first redirecting
to a location and issuing the 503 status code there

Server {
error_page 503 /error_docs/custom503.html;
rewrite ^ /sitedown/ redirect;
location /sitedown {
return 503
}
location /error_docs {
internal;
alias /server/path/to/error_docs/folder;
}
}

Hello!

On Sun, Feb 19, 2012 at 03:45:15PM +0300, Nginx U. wrote:

   ...

   error_page 503 = @sitedown;
   return 503
   location @sitedown {
           root /server/path/to/folder;
           # Don't you wish try_files could accept a single parameter?
           try_files $uri /custom503.html;

Unless you have $uri file, this will do an internal redirect to
/custom503.html, triggering the same 503 again. You have to
process request in the location in question to make things work.

Maxim D.

On 19 February 2012 16:04, Maxim D. [email protected] wrote:

Unfortunately, this doesn’t appear to work as expected either
try_files $uri /custom503.html;

Unless you have $uri file, this will do an internal redirect to
/custom503.html, triggering the same 503 again. You have to
process request in the location in question to make things work.

Thanks.

I got a working config where I first redirect to a location and issue
the 503 status there.

Now, don’t you really, really wish try_files could accept a single
parameter?? :slight_smile:

Thanks for your help.

On 19 February 2012 15:23, Nginx U. [email protected] wrote:

Can’t wait for the solution!!

I’ll try the named location suggestion first of course

On Sun, Feb 19, 2012 at 8:06 PM, Nginx U. [email protected] wrote:

Thanks.

I got a working config where I first redirect to a location and issue
the 503 status there.

What’s the problem with placing return 503 in location / { } block?


O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Sun, Feb 19, 2012 at 9:01 PM, Nginx U. [email protected] wrote:

What’s the problem with placing return 503 in location / { } block?

None whatsoever. Did anyone say there was one?

Just wondering. Also I couldn’t make the method with rewriting work. I
got 302’d ad infinitum.


O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On 19 February 2012 16:55, Edho A. [email protected] wrote:

On Sun, Feb 19, 2012 at 8:06 PM, Nginx U. [email protected] wrote:

Thanks.

I got a working config where I first redirect to a location and issue
the 503 status there.

What’s the problem with placing return 503 in location / { } block?

None whatsoever. Did anyone say there was one?

On 19 February 2012 18:06, Nginx U. [email protected] wrote:

This is what actually works:

Small amendment:

Server {
error_page 503 /error_docs/custom503.html;
if ( $request_uri !~ .(gif|png|css|js)$ ) {
set $m “T”;
}
if ( $request_uri !~ ^/maintenance/$ ) {
set $maint “${maint}T”;
}
if ( $maint = TT ) {
rewrite ^ /maintenance/ redirect;
}
location /maintenance {
internal;
return 503;
}
location /error_docs {
internal;
alias /server/path/to/error_docs/folder;
}
}

Sorry …

Server {
error_page 503 /error_docs/custom503.html;
if ( $request_uri !~ .(jpg|gif|png|css|js)$ ) {
set $tt “T”;
}
if ( $request_uri !~ ^/maintenance/$ ) {
set $tt “${maint}T”;
}
if ( $tt = TT ) {
rewrite ^ /maintenance/ redirect;
}
location /maintenance {
internal;
return 503;
}
location /error_docs {
internal;
alias /server/path/to/error_docs/folder;
}
}

On 19 February 2012 17:46, Edho A. [email protected] wrote:

On Sun, Feb 19, 2012 at 9:01 PM, Nginx U. [email protected] wrote:

What’s the problem with placing return 503 in location / { } block?

None whatsoever. Did anyone say there was one?

Just wondering. Also I couldn’t make the method with rewriting work. I
got 302’d ad infinitum.

That’ll be because none of the code I posted is actually real. They
were just to help get an answer.

This is what actually works:

Server {
error_page 503 /error_docs/custom503.html;
if ( $request_uri !~ .(jpg|gif|png|css|js)$ ) {
set $tt “T”;
}
if ( $request_uri !~ ^/maintenance/$ ) {
set $tt “${tt}T”;
}
if ( $tt = TT ) {
rewrite ^ /maintenance/ redirect;
}
location /maintenance {
internal;
return 503;
}
location /error_docs {
internal;
alias /server/path/to/503_status/folder;
}
}

Arrggghhh!

Server {
error_page 503 /error_docs/custom503.html;
if ( $request_uri !~ .(jpg|gif|png|css|js)$ ) {
set $tt “T”;
}
if ( $request_uri !~ ^/maintenance/$ ) {
set $tt “${tt}T”;
}
if ( $tt = TT ) {
rewrite ^ /maintenance/ redirect;
}
location /maintenance {
internal;
return 503;
}
location /error_docs {
internal;
alias /server/path/to/error_docs/folder;
}
}

Finally I promise :slight_smile:

Nevermind, I just got this awesome idea: if ($uri !~ ^/error_page/) {
return 503; }

(seems to be working on my simple test)

On Sun, Feb 19, 2012 at 10:23 PM, Edho A. [email protected] wrote:

}
location /error_docs/ {
internal;
alias /server/path/to/error_docs/folder;
}
}
#############


O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On 19 February 2012 18:54, Edho A. [email protected] wrote:

#############
}
#############

Your method will work if you only a few location blocks active to
which you can easily add the return directive.

The one I suggested works in my case where I have several location
blocks.
I have just put the relevant bits into a file and can include it when
I need to take the domain down.
It also allows for the inclusion of images, css. js and similar
resources.

With these things, there is no single answer.

On Sun, Feb 19, 2012 at 11:37 PM, Nginx U. [email protected]
wrote:

alias /server/path/to/error_docs/folder;
}
}
#############

Your method will work if you only a few location blocks active to
which you can easily add the return directive.

You can nest all your location blocks in single location / { } block
(and you can put location / { } in location / { }). Just add “location
/ {” before start of other locations (except error page) and “}” after
them.

Also have you tried this one? Instead of plain “return 503;” in server
block:

server {
if ($uri !~ ^/error_page/) {
return 503;
}

}

Because even if “return 503” is capable of returning the page you
want, the css/js/image still won’t work.


O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On 19 February 2012 19:44, Edho A. [email protected] wrote:

Also have you tried this one? Instead of plain “return 503;” in server block:
No, I haven’t and don’t plan to at this time because I have a setup
that works fine as posted earlier with images, css etc all loading as
required.

As said, there isn’t one single answer as the Nginx config allows a
lot of flexibility and if you prefer a different setup, that’s just
fine.

All the best!