| 5:29 pm on Sep 20, 2008 (gmt 0)|
Fairly odd problem....
to your .htaccess file (put it at the top or bottom, it does not matter).
This directive internally rewrites requests for "/" to "/index.htm". See Apache mod_dir for more information.
You should never *redirect* from "/" to /index.<whatever>. This is wasteful of both time and bandwidth, and serves no purpose whatsoever. Plus, it becomes a problem in the future should you decide to go to .php or .asp, for example -- You would have to change your home page's URL, and as a result, lose ranking for several days to many, many months. By using DirectoryIndex or an internal rewrite (mod_rewrite), this problem is completely avoided.
| 5:51 pm on Sep 20, 2008 (gmt 0)|
adding that directive did not work, I still get the same error message.
This was working until I tried to add SSI to our files. I removed all the SSI calls, but now having this problem.
I had this problem on another goDaddy hosted account. I've submitted a service ticket but have not heard back from them.
| 6:04 pm on Sep 20, 2008 (gmt 0)|
If you've removed php calls as well, then you will need to delete this line from your .htaccess file:
AddType application/x-httpd-php .htm .html
Be aware that this line is a 'kludge' -- That is, it is technically incorrect, but is a legacy of the early php implementations.
What it says is that files of type .htm and .html should be sent to the client (e.g browser or robot) with a Content-Type (MIME-type) HTTP header of "application/x-httpd-php". This would always cause the client to try to download and execute the php locally, rather that running it on the server. Normally, php intercepts these requests and replaces the Content-Type header with text/html before they're sent to the client. However, if you're no longer running php, then the server will dutifully try to send .htm and .html pages to the client with the "application" header, which will tell the client browser to download rather than render the page.
You can check your client and server HTTP headers with the very-useful "Live HTTP Headers" add-on for Firefox/Mozilla browsers. It provides often very useful, but hopefully not unpleasantly-surprising information about the details of your client-server transactions.
| 6:15 pm on Sep 20, 2008 (gmt 0)|
[Ooops. Left tab open for an hour before replying.]
| 6:41 pm on Sep 20, 2008 (gmt 0)|
I still do run php scripts on our site, so I need that directive.
Not sure what to do, I guess wait for that GoDaddy 'we'll get back to you in a hour' e-mail for a solution.
| 6:55 pm on Sep 20, 2008 (gmt 0)|
In the meantime, check your headers, as suggested above. This will give you more information to use while dealing with GD help... Sometimes, "help" desks need *your* help -- to help them help you... :)
Your index page should be served with a Content-Type header reading "text/html", and there should be only one Content-Type header in that server response.
| 7:07 pm on Sep 20, 2008 (gmt 0)|
I added the 'live header' addon, tired to run the page though Firefox, I get the following error message:
'You have chosen to open
which is a: application/x-httpd=php
from 'my web site'
What should Firefox do......"
The Live HTTP header dialog box is empty.....
| 7:13 pm on Sep 20, 2008 (gmt 0)|
Be sure the add-on is enabled, and that the "Capture" checkbox is ticked. Also, be sure to completely-flush your browser cache before each and every test -- especially after changing any code on your server.
It's likely that you're seeing a locally-cached page, and that is why LHTTPH didn't register anything; No request will be sent to your server if the page has been recently cached in your browser and your server has not been configured to send the "Cache-Control: must-revalidate" header.
| 7:16 pm on Sep 20, 2008 (gmt 0)|
So finally called GoDaddy, but they were very quick top tell me that it's my problem, not theirs....but they did offer me a discount on hosting account that is due in two weeks.
| 7:21 pm on Sep 20, 2008 (gmt 0)|
If you did not flush your browser cache before testing the DirectoryIndex patch above, I'd suggest that you flush your cache and try it again... Just in case.
Stale cached results are the bane of testing server-side code. I often just disable the cache when preparing for a day of testing, just to save the aggravation...
Don't forget to re-enable it, though, or you'll drive yourself and other Webmasters batty by re-fetching every page and every image, script, etc. on every page -- every time. This can make a mess of your log files -- caching is normally a very good thing.
| 7:26 pm on Sep 20, 2008 (gmt 0)|
Is that = a typo here or in your .htaccess file? It should be a hyphen:
| 7:50 pm on Sep 20, 2008 (gmt 0)|
Yes typo, it is a '-' in the actual file.
| 7:51 pm on Sep 20, 2008 (gmt 0)|
While testing, I have a parameter flag I can set which stops Google Analytics running on the test page, for me, if it is out somewhere on the live part of the site.
It is automatically disabled in the /test/ folder and any dev or test subdomain. In those cases, the page detects *where* it is being served from, and does this automatically. I don't have to *do* anything when moving code from a test server to a live server to enable/disable analytics.
| 7:54 pm on Sep 20, 2008 (gmt 0)|
Here is the 'live http' listing:
http www xyz co uk
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/2008070208 Firefox/3.0.1
If-Modified-Since: Sat, 20 Sep 2008 16:28:24 GMT
HTTP/1.x 200 OK
Date: Sat, 20 Sep 2008 19:52:09 GMT
Last-Modified: Sat, 20 Sep 2008 19:25:45 GMT
Keep-Alive: timeout=15, max=100
X-Antivirus: avast! 4
| 8:27 pm on Sep 20, 2008 (gmt 0)|
So as you can see, the Content-type is incorrect, and the client will try to find a plug-in or an application to execute the contents of the server response, rather than rendering it as an HTML page.
You might want to look at the page contents (go ahead and download it, then open with a text editor). If it is HTML, then the problem is only that the server is sending the wrong Content-type. If it is actually the PHP source code, then that means the server is no longer 'running' your PHP script to generate an HTML page, but just serving the PHP file contents directly to the client. That would indicate that in addition to the .htaccess configuration directives previously modified or removed, something else has been deleted as well, so your PHP scripts are no longer executing on the server.