Custom 503 Error Page

[Corey Donohoe]

On 2/2/08, Douglas A. Seifert <dseifert at searchspark.com> wrote:
> > > Hmm... that doesn't seem to work either.  Is it possible that `return xxx;`
> > > always generates the internal response?
> > >
> > > The only thing that would achieve the desired result in this case is
> > > proxying to some blackhole which would cause the 503 to be caught and
> > > rewritten according to the error_page directive.
> >
> > Oops. Sorry, I missed. The real problem is that with suggested
> > configuration (i.e. always return 503 at server level) there
> > is no way to reach /system/maintenance.html file for nginx.
> >
> > So, it tries to get /system/maintenance.html for error body, and
> > gets yet another 503. So it has to return hardcoded content.
> >
> > The only solution is to allow nginx to access
> > /system/maintenance.html somehow. Something like this:
> >
> >      error_page 503 /system/maintenance.html;
> >
> >      location / {
> >          if (-f ...) {
> >              return 503;
> >          }
> >      }
> >
> >      location /system/maintenance.html {
> >          # allow requests here - do not return 503
> >      }
> >
> > The if{} block should be in all locations where access should be
> > disallowed, but not for /system/maintenance.html itself.
> >
> > Maxim Dounin
> >
>
> Doing it that way gets me the custom content, but with a 200 OK
> response. :(  I'm afraid the only way I will be able to do this is to
> recompile nginx with the default 503 content set to what I want it to be
> (that's my current workaround).  Or dig up my extremely rusty C skills
> and try to figure out the bug, if any.
>
> Thanks,
> Doug Seifert
>
>
Hey Doug,

We do something like http://forum.engineyard.com/forums/3/topics/22 at
Engine Yard.  I did it earlier this week for a client.  Is this
approach any different than the approaches you've tried thusfar?

-- 
Corey Donohoe
http://www.atmos.org/