Welcome to WebmasterWorld Guest from 188.8.131.52
I can bring up the www.xyz.com/index.htm, but when I try the root directory name, www.xyz.com, I get a 'File Downlaod - Security Warning' dialog box.
I'm assuming that his is a .htaccess file issue. Our .htaccess files is as follows:
AddType application/x-httpd-php .htm .html
Options Indexes FollowSymLinks Includes
Thanks in advance....
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.
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.
AddType application/x-httpd-php .htm .html
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.
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.
'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.....
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.
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.
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.
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
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.