[nycphp-talk] not including '.php' in URI
Tim McEwen
tim at tmcode.com
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
request
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).
-Tim
On Mar 21, 2006, at 11:11 AM, inforequest wrote:
> Chris Shiflett shiflett-at-php.net |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
>
> www.site.tld/nicename causes Apache to run /nicename/index.php
> or
> www.site.tld/nicename causes Apache to run /nicename/index.html
> (which
> is a PHP script, or maybe not)
> or
> www.site.tld/nicename is merely a referrer reference because PHP.ini
> runs a (PHP script) controller every time
> or
> www.site.tld/nicename 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
> http://www.seo-fun.com
>
>
>
>
>
>
>
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> New York PHP Conference and Expo 2006
> http://www.nyphpcon.com
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
More information about the talk
mailing list