Removing index.php from url

Server NGINX
1

Hey all,
I have a server with nginx 1.2.5 and php-fpm 5.3.3 installed. I have a
web
application built on top of zend framework and the routing passes
everything
thru a index.php file.
So while http://www.domain.com/contact works -
Domain.com will fetch the same content
aswell
and I’d like to get rid of it for SEO purpose.

Here’s my configuration - right now there’s a if statement that takes
care
of removing the index.php however I know that if is evil and therefore
shouldn’t be used. On top of that the only instance that won’t work well
is
Domain.com which in this case instead of
redirecting to
www.domain.com will just display a blank page with a 301 status code.

On top of that - if you guys spot any problem with my config - I’d love
to
hear what I am doing wrong and what can be improved.

server {
listen *:80;
server_name domain.com;
return 301 $scheme://www.domain.com$request_uri;
}
server {
listen 80;
listen 443 ssl;
server_name www.domain.com;
ssl_certificate /etc/nginx/certs/www.domain.com.crt;
ssl_certificate_key /etc/nginx/certs/www.domain.com.key;
error_log /var/www/domain/logs/error_log warn;
root /var/www/domain/html/http;
index index.php;
client_max_body_size 150m;
error_page 403 404 http://www.domain.com/notfound;

if ( $request_uri ~ “^/index.php” ) {
rewrite ^/index.php(.) $1 permanent;
}
location / {
rewrite ^/wanted/feed$ /feed?filter=wanted permanent;
try_files $uri $uri/ /index.php?$args;
}
location /min {
try_files $uri $uri/ /min/index.php?q=;
}
location /blog {
try_files $uri $uri/ /blog/index.php?q=$1;
}
location /apc {
try_files $uri $uri/ /apc.php$args;
}
location ~ .php {
include /etc/nginx/fastcgi_params;
fastcgi_param HTTPS $https if_not_empty;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SERVER_NAME $http_host;
fastcgi_pass 127.0.0.1:9000;
}
location ~ ^.+.(ht|svn|git)$ {
deny all;
}

Static files location

location ~*
^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$
{
expires max;
}
}

Posted at Nginx Forum:

2

2012/12/03 7:09 “adambenayoun” [email protected]:

Hey all,
I have a server with nginx 1.2.5 and php-fpm 5.3.3 installed. I have a web
application built on top of zend framework and the routing passes
everything
thru a index.php file.
So while http://www.domain.com/contact works -
Domain.com will fetch the same content aswell
and I’d like to get rid of it for SEO purpose.

Here’s my configuration - right now there’s a if statement that takes care
of removing the index.php however I know that if is evil and therefore
shouldn’t be used. On top of that the only instance that won’t work well
is
Domain.com which in this case instead of redirecting
to
www.domain.com will just display a blank page with a 301 status code.

location = /index.php { return 301 /; }
location ~ ^/index.php(/.*) { return 301 $1; }

Note that the $1 may or may not work as I never tested that.

listen 80;
if ( $request_uri ~ “^/index.php” ) {
try_files $uri $uri/ /blog/index.php?q=$1;
fastcgi_pass 127.0.0.1:9000;
}
location ~* ^.+.(ht|svn|git)$ {
deny all;
}

Static files location

location ~*

^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$

{
expires max;
}
}

Posted at Nginx Forum:
Removing index.php from url

3

On Sun, Dec 02, 2012 at 07:08:55PM -0500, adambenayoun wrote:

Hi there,

I don’t have a direct answer to your questions, but there is something
I’d like to comment on…

So while http://www.domain.com/contact works -
Domain.com will fetch the same content aswell
and I’d like to get rid of it for SEO purpose.

“get rid of” means: if a request comes in for /index.php/anything,
it should be permanently redirected to /anything.

right now there’s a if statement that takes care
of removing the index.php however I know that if is evil and therefore
shouldn’t be used.

Here’s the thing: why do you believe that? It seems to be a reasonably
common belief.

The wiki page about it, If is Evil… when used in location context | NGINX, has as its first
line: “Directive if has problems when used in location context”. You’re
not using it in location context, so you should be fine. Outside of
location context, I don’t think it counts as any more evil than any of
the rewrite module directives.

Anyway: on to the questions…

On top of that the only instance that won’t work well is
Domain.com which in this case instead of redirecting to
www.domain.com will just display a blank page with a 301 status code.

So: what do you want to happen when someone requests /index.php without
an immediately-following / ? Just process the page, or redirect to / ?

Module ngx_http_core_module for the details, but you can use “location
= /” or “location = /index.php” to handle the “exact” case (which can
involve fastcgi_pass and the like); then “location ^~ /index.php/” for
everything that should be redirected to “no index.php” (possibly with
a map (Module ngx_http_map_module) to find the thing to redirect to); and
then the rest stays as it is.

On top of that - if you guys spot any problem with my config - I’d love to
hear what I am doing wrong and what can be improved.

error_page 403 404 http://www.domain.com/notfound;

That bit possibly does not do what you want.

if ( $request_uri ~ “^/index.php” ) {
rewrite ^/index.php(.*) $1 permanent;
}

With the pure-location setup, that bit becomes unnecessary.

location /min {
try_files $uri $uri/ /min/index.php?q=;

No $args there.

location /blog {
try_files $uri $uri/ /blog/index.php?q=$1;

It’s not obvious what $1 is set to there.

location /apc {
try_files $uri $uri/ /apc.php$args;

No ? there.

Each of those may or may not do what you want. If they work, that’s
fine.

location ~ .php {

location ~* ^.+.(ht|svn|git)$ {

location ~*

An occasional suggestion on the list is to avoid top-level regex match
locations, for ease of reading/scalability reasons.

If you choose to follow that suggestion, those would need to be
rewritten.

It may not be worth you following that suggestion, depending on how your
files are organised.

Cheers,

f

Francis D. [email protected]