[nycphp-talk] not including '.php' in URI

Tim McEwen tim at
Tue Mar 21 14:55:36 EST 2006

For what its worth....

We spent some time agonizing over this issue.  We were already  
spending time stripping out the apache server token, setting  
expose_php=off, etc to minimize the amount of information about our  
site we were exposing.  Advertising the fact that we were using php  
by including the .php seemed to defeat all of these efforts.  We  
thought about using rewrite,  but found that it can make debugging a  
nightmare.  We also investigated using a controller script that  
routed paths to the correct php code.  While this optioned looked  
like the best for a variety of reason (error tracking, logging, etc)  
we decided against it because of the amount of rewriting we would  
have to do. In the end we decided to just drop the .php extension.

If you are concerned about performance when serving static content  
then I would suggest serving content with a separate http server.  In  
my case I use apache to serve up the php scripts and everything  
static is served with a lightweight http server like tux.   The  
lightweight server can still run on the same machine, either by using  
a virtual ip or a different port number.

As far as speed goes,  the amount of time to call a script  with or  
without the file extension is fairly small.  In deciding whether to  
use file extensions or not we used ab to benchmark the two:

Without .php extension:   22.46 requests per second,  44.53  ms per  
With .php extension:   22.54 requests per second,  44.36 ms per request

It was a small enough difference not to matter to us.  That being  
said,  other problems on your server such as slow harddrives  are  
going to amplify that difference some.  That being said,  there are  
much more import areas to focus on if you need to make things  
faster.   For example,  optimizing the php/apache binary, moving our  
content to a ram disk and installing an opcode cache such as apc, the  
above benchmark jumped to 153 requests per second (6.53 ms per request).


On Mar 21, 2006, at 11:11 AM, inforequest wrote:

> Chris Shiflett |nyphp dev/internal group use|  
> wrote:
>> Dan Horning wrote:
>>> it's not a matter of making things faster, b/c it won't, I've
>>> tried, but in actuality you create excessive opportunities for
>>> security breaches, why on earth would you want to make your
>>> life harder.
>> Can you substantiate that claim? My web sites don't use file  
>> extensions,
>> but I doubt you can convince me that this increases my security risk.
>> I know little to nothing about SEO - my decision is based on my  
>> opinion
>> that URLs are basically friendly APIs for the average person. Things
>> like file extensions and underscores don't seem very friendly.
>> Simple is beautiful. :-)
>> Chris
> I appreciate this discussion. It's good stuff. I'd like to see more  
> of it.
> There are so many ways to avoid using file extensions... Maybe it's
> causes Apache to run /nicename/index.php
> or
> causes Apache to run /nicename/index.html  
> (which
> is a PHP script, or maybe not)
> or
> is merely a referrer reference because PHP.ini
> runs a (PHP script) controller every time
> or
> causes Apache to run /nicename (a PHP script  
> with
> no extension)
> or
>  www.ste.tld/nicename causes Apache to run redirect to
> /nicename/controller.php via a rewrite rule
> Each has performance issues, security issues, etc. How can one  
> generalize?
> Chris chooses to accommodate the user, and handles the security and
> performance issues. Isn't that how we all have to do it? Choose a
> strategy and cover the bases?
> -=john andrews
> _______________________________________________
> New York PHP Community Talk Mailing List
> New York PHP Conference and Expo 2006
> Show Your Participation in New York PHP

More information about the talk mailing list