Best practice for URL rewriting with php parameter

Mik J mikydevel at
Thu Nov 12 23:04:50 UTC 2015

Hello Francis,
I tried again your solution from yesterday and didn't manage to make it work
 location = /information { rewrite ^ /index.php?x=information; }
  location = /index.php {
    fastcgi_pass;    fastcgi_param SCRIPT_FILENAME $document_root$uri;
    fastcgi_param QUERY_STRING $query_string;


  location = /information {
    fastcgi_pass;    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    fastcgi_param QUERY_STRING x=information;
You asked me if it's a proxy_pass or a fast_cgi pass, I guess I want a fastcgi_pass. Nginx passes the php work to php-fpm on the same server.

I know that the blocks are properly matched because whenI misconfigure the fastcgi_pass I have the bad gateway message.When it's configured as above it displays a completely blank page.
I have php-fpm configured with 
error_log = log/php-fpm.loglog_level = noticephp_flag[display_errors] = on
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on
I don't know how to debug this blank page thing

However when the x variable can take multiple values x=information or x=something, the second solution you wrote seems to be long. If I had to implement as you suggested, I'd have
location = /information { rewrite ^ /index.php?x=information; }location = /something { rewrite ^ /index.php?x=something; }  location = /index.php {
    fastcgi_pass;    fastcgi_param SCRIPT_FILENAME $document_root$uri;
    fastcgi_param QUERY_STRING $query_string;


I don't know what it could be for the second solution
It's much longer thanlocation = /information { rewrite ^ /index.php?x=information; }location = /something { rewrite ^ /index.php?x=something; }Actually, if I only write this it works
Thank you

     Le Mercredi 11 novembre 2015 20h45, Francis Daly <francis at> a écrit :

 On Wed, Nov 11, 2015 at 06:50:54PM +0000, Mik J wrote:

Hi there,

> I tried both methods but none of them worked. I'm going to look at it more in details (and display the php logs because I just had a blank page).

First configure things so that an explicit request for
/index.php?x=information gives you the response that you want.

Keep it simple, do one thing at a time.

> Also I would like to know why the solution you're offering is a "best practice" ?At first it seems a bit heavy because I'll have a paragraph like that for every x variable (x=information, x=something).

The original question did not have multiple x variables. A different
question probably gets a different answer.

Using "rewrite" instead of "try_files" should have exactly the same
number of location{} blocks.

And it avoids a presumed-unnecessary filesystem check -- what should
happen if the file /usr/local/nginx/htmlinformation exists on your

Using "fastcgi_pass" and friends instead of "rewrite" should also have
exactly the same number of location{} blocks. And it means that nginx
can skip one step of processing -- if the rewrite was going to go to a
location which does exactly this anyway.

It does mean that there are more words involved; but if the number of
location{} block is going to be big, you are probably going to generate
them anyway.

> Considering also that the users URL might not look like the x is an internal rewrite of index.php?x=information

I don't see the difference this makes, in the three cases in question.

In each case you have the request, and a different string as the x= value.

If you choose to use variables in a common location, or something like
that, then you will still need the mapping or request to x= value. If you
knew that the mapping is always "remove the first /", then you wouldn't
need a separate table. But you don't have that now, either.

> I tried two other solutions that workedrewrite /info_1234 /index.php?x=information;
> and
> location = /info_1234 { try_files info_1234 /index.php?x=information; }
> I would like to understand why your solution is better than these, why is it a best practice ?

It means that nginx has less work to do to process the request.

Sometime that is not the thing that you want to optimise for.

Francis Daly        francis at

nginx mailing list
nginx at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list