4

Forbidden in the TOS/AUS of a large number of shared hosting sites is the phrase "Force html to handle server-side code (like php and shtml) to help reduce usage." as a prohibition.

I asked a HostGator tech support guy who supposedly asked someone and came back with "It just means that you can't use HTML to parse PHP to reduce load on the server" which is even more wacky.

I've searched on various combinations of the terms, trying to see if I'd missed some recent new term or technique, but came up short. (Found many tips on setting up apache to serve PHP files as .html) That's how I found the language is used a lot throughout the industry.

Anyone know what this would mean if enforced?

|improve this question

migrated from serverfault.com Dec 15 '15 at 7:12

This question came from our site for system and network administrators.

  • 4
    To me it means go to the next hoster, and skip that one. There's enough quality or adequate hosters out there to not have to play games like that. I haven't seen any real hoster do that for since I can remember, but then again, I don't use cheap bad hosting companies, having learned long ago that they cause me far far far more pain than the few cents I save. What it means is dump the hoster and move before you suffer more pain from other failures they will almost certainly make you suffer. I say this having learned this lesson the hard way, now I refuse to allow clients to use bad hosters. – Lizardx Dec 15 '15 at 7:27
  • 1
    That quoted phrase from the HostGator AUS is badly worded IMO, since it implies that forcing html to handle server-side code would "help reduce usage", but it is clearly the opposite. Elsewhere on HostGator support it is worded better... "to lessen your CPU usage... Avoid using too many scripts, and do not force html to handle server-side code (like php and shtml)." - by this they are saying that you shouldn't be using too many .php files! – MrWhite Dec 15 '15 at 12:38
  • I wasn't suggesting setting up apache to send all html files to php for parsing, I only wanted to know what the devil that clause meant. I found the guides on that matter as part of my initial research. Turns out the bunch of sites using that inane verbiage are mostly EIG, so it's probably just an artifact of a single idiot misunderstanding. That still doesn't clarify what they think it means... – The Nate Dec 17 '15 at 9:16
  • I'm not trying to be short, but since people keep missing my point, I apparently need to wax pedantic a bit: My question never was about whether our not serving files through the parser adds any extra overhead. (It does because Apache works that way. Individually it's not a huge amount, and significance is what's debated, here. That was not my question, though, you see.) I was well aware that using the parser adds some overhead; that's part of why the phrase "to help reduce usage" makes it difficult to interpret that way. I'd like to find out what they meant by their moon speak. – The Nate Dec 20 '15 at 20:03
5

From what I understand what you mean it's simple:

By default, Apache (or other web servers) will send a .html file to the client as is, without further processing, .php files will be processed by PHP first and .shtml files by the Apache SSI processor. Naturally, this will be more compute-intensive then simply sending out the file as is.

However, it's possible to configure Apache to instead also send .html files through the SSI and/or PHP processors before sending them to the client. If most/all of these files don't contain SSI or PHP instructions, this will create a noticeable and useless overhead, which I believe shared hosters want to avoid.

Of course, this overhead will be less dramatic today then 10 years ago so one might start to argue if this restriction is really still necessary, but since there is no real benefit to parse .html files by PHP (after all, you can just name a file .php), I don't see why this should be allowed.

|improve this answer
  • 1
    I would disagree, I view it exactly the opposite. I've always run .html files through php, for the simple reason, which is something I picked up a long, long, long time ago, the extension should have nothing to do with the server side generator, so you can use anything server side. So almost all my sites use .html extensions, and all are php driven. The restriction is plain silly, and is why I don't even consider using such amateur hosting companies, haven't seen any even faintly pro hoster ban such practices. There is no reason to use any company that won't let you do such a basic thing. – Lizardx Dec 15 '15 at 7:25
  • @Lizardx: To each it's own - I like the control this gives me about how my files are processed, and from an operations standpoint, I can understand why a hoster would want to restrict this. – Sven Dec 15 '15 at 7:35
  • 1
    I can't. There's other places where focus and attention can deliver real gains, this is not one of them. I'm actually amazed to see this question in 2015, in 2000 what I wrote was considered best practice. Or no extension, that works fine too, makes very little difference. The notion that they are packing so many sites onto a server that this would make any difference at all means only one thing: this is a very bad company, which should be avoided like the plague, since if their servers are this overloaded, they will certainly fail constantly. – Lizardx Dec 15 '15 at 7:40
3

Having worked for a hosting company for quite a while I can confirm that leaving the default handler for .html files to be PHP leads to huge overhead on the servers. The reason for this is that there are many users who never bother to change that, they just upload some site and leave it as it is. With the default handler set to PHP this means that all .html files on the server, no matter if they are actually PHP are going to be served through the PHP parser, which consumes much more memory and CPU cycles.

Being a shared hosting also means that all of the users(which are usually a few hundred per server) share the same resources. If one of them starts to consume more, the others have to consume less. This means that you have to to limit what users can do to make sure everyone is getting relatively good experience. It a compromise which needs to be done, otherwise you are allowing one(or few) user make to everyone else's experience bad(slow speeds, unresponsive pages etc.)

As for why they actually 'Forbid' changing this on the user side(.htaccess), I don't know, probably for similar reasons. Imagine having a site with 1000 .html files in it and only 2-3 of those have actual PHP code in them. The server will have to parse all those files, even though there is no PHP in them.

Keep in mind that shared hosting is the cheapest solution and there are always some kind of limitations. Prices are so low that everyone is forced to cut any possible corners to keep the business profitable. On the plus side - there are a ton of shared hosting providers, so you can always switch to another one which fits you better.

If you need to do more custom things buy a VPS/dedicated server.

|improve this answer
  • So, you are also pretty sure that this is some technically impaired person's attempt to ban serving all your files through PHP? (I only mentioned that bit because of the "show your work" directive, but I'm unconvinced it didn't overly influence the discussion.) – The Nate Dec 20 '15 at 18:09
  • I'm not sure exactly what it is that you are trying to say? – EvilTorbalan Dec 20 '15 at 18:19
  • I'm trying to figure out of you think that the language used is intended to ban the use of the php parser on all files or if you were just weighing in on the question of server overhead because that was the question dejour and you happen to know the answer. – The Nate Dec 20 '15 at 19:49
  • Well my guess is that this "moon speak" is used to give them the right to block your account of they suspect that you are using too much resources. In other words they will probably let you do the setting but... – EvilTorbalan Dec 20 '15 at 20:18
-1

In case my comment above isn't clear, the entire notion of this is absurd. When you configure apache, or set .htaccess, you are simply telling apache what to do with various extensions. The notion that there is any overhead on a php page, for example, with .html extension, is incorrect. And why would you add php processing to pages without php? The extension is just some letters after the dot. You can have a straight html .php page, or a pure php .html page, makes no difference, and if it somehow does to that hoster, that's a very bad hoster, which will almost certainly make you suffer in many ways.

Since this is something you can set in your .htaccess, or in apache configs, you do it, presumably, because you are planning to use php on the pages, which means, there is as far as I know zero difference or overhead increase if the extension is .html over .php, in both cases, apache hands the processing to php, which then does its thing, and returns the processed page html output to apache, more or less.

I too started with low end cheap hosters, wasted untold hundreds of hours of my life, which I will never get back, working with bad cheap hosters, and now won't do it, there's no reason to, all it costs you is time, a lot of it.

If your time is worth more than about $2 an hour, you will never gain anything or save a cent using low end, or middle grade, hosters. And if your time is worth more than 10 bucks an hour, you will never save a cent using anything but high end hosters, shared or otherwise.

And if your time is worth actual professional salary, then you are making a serious mistake. One I've made many times, or rather, allowed clients to make, but now will not do anymore. I find a few fully invoiced low end hoster failure support instances easily convinces anyone that the cost saving was purely an illusion. Or the site going down the first time any site on the box gets any load, whatever.

"Forbidden in the TOS/AUS of a large number of shared hosting sites is the phrase "Force html to handle server-side code (like php and shtml) to help reduce usage." as a prohibition."

I'd like to offer a suggestion: I have NEVER seen this prohibition on any even mediocre hosting company. Never. Not one single time. So I would take that and add it to the list of "how to identify bad hosting companies". Even bad hosting companies have not done that in my experience, so this must be some seriously low end stuff, but I will resist the urge to get into specifics, except to note I'm not surprised to see the name hostgator mentioned in this context.

|improve this answer
  • 2
    You are completely missing the point and misunderstand the situation. If you tell Apache to send .html files through the PHP interpreter even if they don't contain any PHP code, you will create a real significant overhead by this useless processing. There is a real simple fix for this: Telling Apache to send only files named .php through the interpreter and deliver .html files directly to the client. This has immediate benefits for the provider and for yourself as you can simply send out static files much faster to your users. – Sven Dec 15 '15 at 11:30
  • 1
    The drawback for yourself: Really none, you just have to name your files .php, which is not really an issue. To make it clear: There is no overhead for a PHP fiile named .html compared to a PHP file named .php, but there is a significant overhead for a pure HTML file send through the PHP interpreter. – Sven Dec 15 '15 at 11:30
  • I'd like to thank this poster for letting me add another red flag for bad hosters to my list. I do like straight html sites, I run one myself, just for fun. – Lizardx Dec 15 '15 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.