HTML Parsing in suPHP

There is a very good reason why standard HTML pages are not parsed as PHP scripts and your client absolutely should not be doing this!

Under DSO (Apache module) based PHP, there was a loophole in that you could tell the server to parse HTML files as PHP scripts via .HTACCESS even though you technically were not supposed to be doing that as it can cause some very serious complications that are well beyond the scope of this discussion.

What your client needs to do now is rename all of their .HTML files to what they should already have been originally as .PHP files and then setup a few mod_rewrite commands in their .HTACCESS to map all URL requests to .HTML internally to the corresponding .PHP script files which is how they should have implemented things originally in the first place and not tried to parse HTML files as PHP script files.

(SIDE FYI: And if the client whines about search engine rankings, feel free to slap them upside the head because the above will have absolutely no bearing on their search engine listings and rankings whatsoever!)

 

Actually, far as I can see you totally missed his point because it didn't say what you wanted.

Although he's suggesting renaming the files to .php to make them work better (and more safely) with the webserver, the way he's suggesting to do it does not require you to change the web logic, it would still work the same.

He's suggesting you use a mod_rewrite rule to map incoming .html requests to the (new) real .php extensions, which would solve your problem much more neatly, and much more safely, than the horrible, horrible thing you are trying to do! Good luck!

 

Hello -

I would very much like to know what this reason is, Spiral. I have never heard this before. I have been doing it for some time with no ill effects. And there are several reasons why I don't want to use a PHP extension.

1) I have read that some people do not "trust" pages that don't end in HTML, and I certainly don't want that to be the case for a website where I'm trying to sell something!

2) I have also read that Google prefers pages that end in HTML.

Unfortunately, I don't have references for either of these two "rumors", but I don't want to take any chances unless it's really necessary. The only alternative for me would be to rewrite the PHP sections of my pages in Perl, and SSI include them.

BTW, there is quite a good discussion, showing several different methods of parsing HTML files as PHP at How To Parse HTML Files As PHP - Web Development Blog.

 

The rest of the internet knows that .php is a standard extension. Check almost any eCommerce site and you'll see files ending in .php, including, for instance, facebook.com. I'm sure that somewhere there are people who do beleive this; but you can be sure they're a tiny minority. There are also people that beleive that all eCommerce is secure, or insecure, or that PHP is the devil's tool, or whatever ... you get my point ...

Completely and categorically untrue, just a rumour. If you do any basic research you'll see that this is a very old rumour, but it'svery definitely just that - a rumour.

One of the reasons why it's bad practice to do what you're doing here is that it can lead to database passwords (in php source) being exposed as plain text by the web server. The web server otherwise would protect .php extensions.

Secondly, it's just plain bad, messy, practice. Forgive my directness, but if I saw this being done on a website I would conclude that the people responsible for it didn't know their stuff. Do you really want people coming to that conclusion about your good self?

 

I stand by my original statement, brian:

I myself called them "rumors", as you can see. BTW, where are the references for your assertions?

As to your reasons, 1) the websites on which I'm doing this have no databases, and 2) Calling it a "bad, messy practice" does not make it so. The reference I posted is one of many that can be found by searching Google for "parse HTML as PHP", and I didn't find one of the sites listed that disparaged its use. Also, I don't forgive your directness. Your post sounds like a "flame" to me. Can't we do without the ad hominem arguements? I'm pretty confident that I "know my stuff". I've been a programmer for over 45 years.

 

Apparently you did not bother to read my first message posted above since I didn't say you couldn't have all your URLs end in .html as far as users and search engines are concerned, rather that you should *NOT* parse HTML files as PHP scripts!

You can still have web addresses end in .HTML to the outside world while internally within the server have the scripts properly setup as .PHP and my last post above tells you how to do just that!

Regarding your question, it substantially increases server loads (multiplied by the number of sites doing this) and has been known to cause substantial memory leak / corruption issues within Apache.

Considering that more than 71% of the world wide web is directly PHP based (along with .php addresses), I highly doubt that assertion.

Irregardless, if you followed the instructions in my previous post, you could have .HTML urls if you so wished without violating setup protocols or possibly endangering your server stability.

Unfortunately, the inherent problems this causes aren't as widely known by average users and lessor experienced administrators as they should be as there hasn't been enough publicity mainly due likely to other concerns specifically dealing with security related matters if this were to get wider attention. More experienced administrators have all known about this issue for quite a while though and have been the base to try to routinely steer other users away from doing these things even if those users themselves do not fully understand the reasons behind doing things differently.

This I can tell you first hand, much more than you could possibly ever realize, that the above statement is absolutely and completely false!

In earlier versions of the web crawling system at Google, it was indeed programmed to read only .HTML and .HTM files specifically ignoring most of .ASP, .CGI, and .PHP files out there but that is no longer the case and there have been a great many revisions between that time and now including a period of slightly "misleading" rumors deliberately spread to trip up SEO people out there.

Many things have changed however I wouldn't dare suggest the logic might currently be reversed now or that PHP might have higher priority, I certainly wouldn't say that at all.

Again, it is very clear you didn't read my previous post!

If you did what I said, you wouldn't have to do anything to the files whatsoever other than rename the files and there would be absolutely
no file editing to do (except .htaccess)!

URLs to the outside world would continue to use .HTML or could actually connect by .PHP as well as it really wouldn't matter either way. The .HTML requests would be silently remapped to the .PHP files and by silent, I mean there is no way for the visitor to know that the URL has been remapped if you do it correctly.

 

Thanks, Spiral

You're quite right about my not having read your first post correctly. I guess I was too quick on the draw.

Thank you for explaining what's wrong with parsing HTML as PHP. It's too bad that so many people are still promoting it. I will inform my webhost of the inherent dangers you have pointed out. And I will definitely take your advice, and redirect my requests for .html ==> the corresponding new .php files that I'll put in place of the .html's I had.

For the benefit of others reading this thread who aren't as familiar with .htaccess, would you as the expert please give the mod_rewrite code for a typical redirect?

It's refreshing to have actual evidence, rather than opinions. Thanks again.

 

Here are a few:
Sitepoint FAQ: Search Engine Optimization - SitePoint Forums
Dynamically Generated Pages and Query Strings - SEO FAQ - High Rankings
(sitepoint has a well known and established SEO forum, you probably know it for it's PHP discussion, I have coffee across from their office every day FWIW)

Here's a link into the generic Google FAQ which might prove useful (I couldn't find any mention of the .php issue specifically):
Site management - Webmasters/Site owners Help

Granted, but the fact that it's mentioned everywhere doesn't make it a good practice either! A key principle of good system administration is keeping practices obvious and clear. As in software development, that which is obvious is easy to maintain; that which is obscure will lead to problems in the future.

In this case, Spiral's compelling point about memory leaks aside (which was new to me), I can see two reasons not to do it:

1. it's a non-standard practice which could lead to issues in the future
2. it can lead to exposure of passwords or code if the system fails to parse the PHP file

Of course, I'm sure you don't have passwords in your .html/PHP files, but you were asking a general question.

Profound apologies for sounding caustic; no offence was intended, despite my poor wording.

The skill of being a software developer is commonly mistaken for the skill required to be a good system administrator. While you are probably a brilliant and thoroughly competent software developer, that does not make you a highly skilled system admin. Over my many years as a system admin I've dealt with many genuinely clever developers who thought they understood system admin principles, but in fact didn't, and made horrible mistakes. In fact, the skill of system admin and the skill of software development are far apart, both requiring years to learn. At one stage of my career I was a senior developer, now as software development has evolved I now know next to nothing about software development!

One of the key principles of system admin is building simple, clear systems that are easy to maintain. The more obvious and standard they are in their functioning, generally the easier they are to maintain. It takes some experience to understand this, and more skill to know what could be considered as obvious. Although this is similar to software development concepts of reduced system complexity, sufficient perspective is required in order to know what is simple and what is complex.

It's a common developer mistake to want to rewrite the way a system works; no fault of the developer here, it's the role of a good system admin to put brakes on that process by saying why and where that makes sense, as of course, there are times when it does and times when it doesn't, and those are often only clear from the larger system perspective. In this case, changing the meaning of an .html file to include parsable PHP code is one of those where it doesn't make sense, in my opinion, based on the above mentioned links/problems/What Spiral Said above.

Again, apologies for the careless offence.

 

The handler using suphp is:

AddHandler application/x-httpd-php5 .php

or

AddHandler application/x-httpd-php4 .php

Then you can just add the .html or .htm after the .php