Error_page

I just noticed that the error_page directive strips post data… I
thought a
patch was submitted for this years ago?

Any chance of getting this patched? Us people using dynamic sites where
we
use internal redirects like: /index.php?page=$uri
would apreciate it.

SplitIce

Your should not be using error pages for creating clean URLs, they are
for errors, nothing else. See this feature for making clean URLs:
http://wiki.nginx.org/NginxHttpCoreModule#try_files

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,186315,186346#msg-186346

On Mon, Mar 28, 2011 at 11:16:00PM +1100, SplitIce wrote:

Hi there,

I just noticed that the error_page directive strips post data… I thought a
patch was submitted for this years ago?

As currently implemented, if the error_page value starts with a /,
then the internal request for it is a GET (or HEAD).

The post_data is provided as part of the request, but the receiving side
probably won’t do much useful with it.

If the error_page value starts with a @, the internal request matches
the original one.

(Any other error_page value results no internal request, which is
probably not what you want.)

Any chance of getting this patched? Us people using dynamic sites where we
use internal redirects like: /index.php?page=$uri
would apreciate it.

As per http://wiki.nginx.org/HttpCoreModule#error_page, you might find
that something like

error_page 404 = @index;
location @index {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_pass unix:php.sock;
}

does, or can be adapted to do, what you want. But test all the cases
you care about before deploying :wink:

Good luck with it,

f

Francis D. [email protected]

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