Domain name does not direct to index.htm

[Meat Curtian]

Hi,
My web site www.xyz.com does not redirect to www.xyz.com/index.htm.

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....

Factor

[jdMorgan]

Fairly odd problem....

Try adding:

DirectoryIndex index.htm

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.

Jim

[Meat Curtian]

Hi JD,
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.

Factor

[jdMorgan]

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.

Jim

[g1smd]

DirectoryIndex index.htm

[Ooops. Left tab open for an hour before replying.]

[Meat Curtian]

Hi Jim,
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.

Factor

[jdMorgan]

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.

Jim

[Meat Curtian]

JD,
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.....

HFactor

[jdMorgan]

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.

Jim

[Meat Curtian]

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.

Classic....

[jdMorgan]

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.

Jim

[encyclo]

application/x-httpd=php

Is that = a typo here or in your .htaccess file? It should be a hyphen:

application/x-httpd[b]-[/b]php

[Meat Curtian]

Yes typo, it is a '-' in the actual file.

[g1smd]

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.

[Meat Curtian]

Jim,
Here is the 'live http' listing:

http www xyz co uk

GET / HTTP/1.1
Host: www.xyz.co.uk
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Sat, 20 Sep 2008 16:28:24 GMT
If-None-Match: "e2feb1-3760-48d524a8"

HTTP/1.x 200 OK
Date: Sat, 20 Sep 2008 19:52:09 GMT
Server: Apache
Last-Modified: Sat, 20 Sep 2008 19:25:45 GMT
Etag: "e2feb1-3760-48d54e39"
Accept-Ranges: bytes
Content-Length: 14176
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/x-httpd-php
X-Antivirus: avast! 4
X-Antivirus-Status: Clean

[jdMorgan]

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.

Jim