Best practice for URL rewriting with php parameter

[Mik J]

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 127.0.0.1:9000;    fastcgi_param SCRIPT_FILENAME $document_root$uri;
    fastcgi_param QUERY_STRING $query_string;
  }

and

  location = /information {
    fastcgi_pass 127.0.0.1:9000;    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 127.0.0.1:9000;    fastcgi_param SCRIPT_FILENAME $document_root$uri;
    fastcgi_param QUERY_STRING $query_string;
  }

or

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 daoine.org> 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
filesystem?

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 variable.nginx.org/info_1234 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.

    f
-- 
Francis Daly        francis at daoine.org

_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx


 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20151112/06df3c40/attachment.html>