Posted by Jerry Stuckle on 11/09/06 19:45

Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>
>>Michael Fesser wrote:
>>
>>Also, I have some customers with .php pages which really are static.
>>But why use PHP for some other function such as processing form data.
>
>
> There are many more nice things I use PHP for, even if the output may be
> static (for a while). If I can use a tool and get some benefits from it,
> I use it.
>
>
>>Also, he never said *all* his pages were static. Telling the web server
>>to process *all* .html files as php files is an unnecessary overhead.
>
>
> Who cares? That's what a server is for. You won't be able to notice a
> difference in time between a plain HTML file delivered as-is and another
> HTML file, parsed by PHP. Even with PHP-(Fast)CGI the difference is too
> small. The transfer over the network takes much more time.
>

Your hosting company, for one, unless you're on a dedicated server.
You're needlessly taking cpu cycles away from other sites on the server.

> And BTW: Unnecessary 301 redirects are no overhead? Not much for the
> server, but for all the clients and the network.
>

Very little compared to unnecessarily parsing .html files. mod_redirect
is quite short and quick in its operation - especially if the redirect
is in the httpd.conf file. But even in .htaccess it's quite fast.

>
>>>But of course you can also use SSI if you like - just configure the
>>>server to parse .html files for SSI directives. And if you want to use
>>>it all at the same time, you can do that as well:
>>>
>>>http://example.com/static.html
>>>http://example.com/phpscript.html
>>>http://example.com/perlscript.html
>>>http://example.com/ssi.html
>>>
>>>It just depends on the server configuration (in this case for example
>>>with content negotiation and MultiViews).
>>>
>>
>>Yep, and the more you tell the server it has to parse, the more CPU time
>>it takes.
>
>
> That's his job.
>

And it's just plain sloppy programming or laziness to force it to do
more than is called for in a case like this.

>
>>>That's a broken design. There are many valid reasons to keep all such
>>>technical stuff out of URLs.
>>>
>>
>>Not at all. No "technical stuff" in the url at all. You're just
>>redirecting index.html to actually retrieve index.php instead.
>
>
> A 'php' in the URL is technical stuff that doesn't belong there. A URL
> describes a resource, not details about the way it is generated.
>

That may be your opinion. The extension just allows the server to do
the most efficient processing of the file. You could call it .xyz for
all I care - just set up the correct file type in Apache.
>
>>No extension?
>
>
> Exactly. Reliable, long-living (in other words: "cool") URLs don't need
> an extension, simply because it avoids a lot of problems.
>

Then your definition of "cool" varies from almost all of the rest of the
world. How many sites do you see with no extensions, for instance
(other than your own, of course).

>
>>UGH - no, DOUBLE UGH! Vomit! Wash your mouth out with soap!
>>
>>Extensions were created for a purpose - to let the server know what
>>needs to be handled by which processors.
>
>
> Concepts like "directory", "file", "extension" don't exist in URLs.
> A URL doesn't describe a file, but a resource.
>

Yep, it describes a resource. One of the types of resource it describes
is a file. And when it's referring to a file on a server, the extension
is important. Not only .php, but things like .gif, .png, and others
come to mind.


> You only need an extension if you directly map a URL onto the server's
> filesystem. That's the most common, but not the only way. Of course on
> the server the files still have their extension, but there's no need to
> show it in a URL.
>

No, it's not the *only* way. But it's the most common - AND THE MOST
EFFICIENT.

>
>>To bypass that creates a
>>completely unnecessary load on the server.
>
>
> If your server gets into trouble because of some little lookups and
> simple pattern matching then you have a _real_ problem.
>

Yep. You have a problem because you create unnecessary load on the server.

> You should care more about your clients (users, search engines) than
> about the server and make things as easy as possible for them. Using the
> right tools at the right time to satisfy the clients, that's the whole
> point. Ignoring these tools just because they may cause some more CPU
> load now and then is - sorry - stupid (no offense intended).
>
> Micha

I do care about my clients - especially the users. And the search
engines handle 301 redirects quite handily - as I have mentioned before.

And I do use the right tools at the right time. That's why I tell
Apache to parse .php files for PHP code, and not to parse .html files
for it.

And expecting the server to do your work for you is just plan lazy.
Sorry if it offends you - but that's how I see it.

Now - one other thing. You may get by with this on a site with 20 pages
and 1K hits/day. But try sites with 10K+ pages, and over 1M hits/hr.

There is a huge difference in the processing time required.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]