Custom error pages - current limitations

[Luigi Perroti]

Hi,

I'm rather new to nginx and I would like to have a confirmation that
the following scenarios can't be handled with the current
implementation.

1) When a client sends a request without the Host: header nginx
returns an hardcoded 400 response.
Actually it isn't possible to use a custom error page in this situation.
I tried to handle this using the "root" and "error_page" directives in
the http section but it didn't work.

2) Consider this simple config file snippet. It's from a configuration
file with only one server, every request is passed to a fastcgi server
which always processes the same script:

server {
   ...
   location / {
      fastcgi_pass   127.0.0.1:1234;
      fastcgi_param  SCRIPT_FILENAME    /script.php;
      fastcgi_param  SCRIPT_NAME        script.php;
      fastcgi_intercept_errors off;
      ...
   }

}

>From what you can see I want to handle all kinds of error codes from the script.
Still there is an exception to that, the "500 Internal server error" response.

If the fastcgi server returns this error nginx will do nothing and
each browser will handle this situation differently.

If I'm not mistaken there is no way for me to define a custom error
page that will be triggered only for the 500 code.
In fact, if I set "fastcgi_intercept_errors on;" nginx will also
handle all the other error codes.


Is there any workaround to handle these scenarios?

Maybe having a directive in the http section that maps a certain
status code to a static file could be useful in these situations and
more.

No matter what, before returning the page to the client check if the
status code is handled by this directive. If it is simply return the
associated file as the response body.

Moreover it should also be possible to define an absolute path for the
file, independently from the document root. To avoid having to mess
with the "internal" directive.

I suppose that when this feature is enabled performance would take a
hit, but I'd accept this gladly for the increased versatility.

Any consideration would be most welcome, thanks!

Regards,
-Luigi