WordPress MU

I'd appreciate any pointers for where to look with this one. It doesn't make sense to me, so I need to learn a bit more but don't know where to focus.

Attempts to use IE to login to new blogs fail. Clicking the link to wp-login.php results in IE wanting to download/save the wp-login.php file instead of running the script and displaying the login username/password dialogue box. Firefox and Safari work normally.

Example problem blog: http://edubuzz.org/blogs/p7yester2008/wp-login.php
Any older blogs tested, e.g. http://edubuzz.org/blogs/student2/wp-login.php , have been OK.

There is a similar previous post http://mu.wordpress.org/forums/topic.php?id=6216 .
In that one, disabling plugins was the solution. I have disabled all plugins, but that hasn't helped.

The problem has been replicated with a number of different PCs, with both IE6 and IE7.
The problem has only been seen since 1.3.3 upgrade.
The site uses WPMU object caching ((define('ENABLE_CACHE', true);). Switching that off hasn't helped.

Setting Apache LogLevel to debug doesn't generate any helpful errors in error_log.
PHP is logging (E_ALL & ~E_NOTICE) to syslog but nothing there looks relevant.

Environment is: WPMU 1.3.3, Apache 2.0.55 Ubuntu, PHP V5.1.2, using CGI/1.1 gateway interface, My SQL 5.0.22

Today I've gathered some more information. It points to encoding, but I can't see how the encoding-related difference I've found could cause the symptoms I'm getting. Does anyone know if there could be a link, or have a better idea?

Details:
1. If I use IE to log in to an older blog which doesn't show this problem, the backend menu options work.

2. If I stay logged in and change to the backend of a problem blog, any attempt to use a menu option there, such as Write, results in an attempt to download/save the corresponding PHP script.

3. The new blogs which have this problem have been created with "Encoding for Pages and Feeds" (under Options/Reading) left blank - I don't know why. Older blogs without this problem have it set to UTF-8. DB_CHARSET is set to 'latin1' in wp-config.php following problems with display of some characters after 1.3.3 upgrade.

4. Encoding value in Options / Reading can be manually changed to UTF-8, and that gets stored OK, but it doesn't solve the problem.

5. A database mysqldump file has create table statements which specify latin1 encoding for all tables of both faulty and working blogs, e.g.

CREATE TABLE wp_1007_postmeta (
...
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Raised call with hosting company. They claim that the problem is with .htaccess rewrite rules, but haven't provided any evidence to support that.

The right files are being located, so rewrite seems to be happening correctly. Now puzzled. Don't see how an error in rewrite rules could cause the URL to be correctly rewritten to point to the correct script files, but cause them to be downloaded, not processed? And only for some blogs?

What headers are your servers sending? That's probably where the problem lies.

Thanks macgruder, I'll check that.

I have same problem after upgrade to 1.5.1. It gives error ciode 302 for every single post/ My installation is subdomains MU

@macgruder: Thanks, this gives a clue. Blogs that work send:

Content-Type: text/html; charset=UTF-8

Those that don't (newer blogs created since 1.3.3 upgrade) send:

Content-Type: ; charset=UTF-8

Next question is why...

Editing blogs shows that faulty blogs have no "Html Type" field, which exists and is set to text/html on healthy blogs.

Have you tried hard coding that part into wp-login.php, to verify that's the issue?

Thanks lunabyte, I've now tried that. Replacing (line 37):

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

with

<meta http-equiv="Content-Type" content="text/html; charset=<?php bloginfo('charset'); ?>" />

led to wp-login.php still wanting to download in IE.

And examining headers with Live HTTP headers shows that we still have Content-Type blank.

Extract from Live HTTP headers:

http://edubuzz.org/blogs/rossbiology/wp-login.php

GET /blogs/rossbiology/wp-login.php HTTP/1.1
Host: edubuzz.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
...

HTTP/1.x 200 OK
Date: Wed, 21 May 2008 22:58:45 GMT
Server: Apache/2.0.55 (Ubuntu) mod_ssl/2.0.55 OpenSSL/0.9.8a
X-Powered-By: PHP/5.1.2
...
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: ; charset=UTF-8

I've now found that the problem blogs are being created without most of the options data that should be visible in the Edit interface. I've confirmed that by examining the wp_<blog ID>_options tables.

The missing fields include "HTML Type", which is normally set to text/html. This is probably why HTML headers are missing this info, leading to IE offering to download/save the login.php file.

Have you added the option and confirmed that was what caused it? You might try upgrading to latest trac version.

Contact your host. Chances are they are using a program called eAccelerate that is causing this.

@MrBrian: Creating a string of test blogs (using Site Admin/Blogs/Add Blog) I've found that every second blog is created properly. (They have the full set of "Edit Blog" settings, including "HTML Type", work properly in IE, and have the correct HTML header as follows:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />)

What I now need to figure out is how on earth the same 1.3.3 scripts (even with all plugins, mu and user, removed) can alternately produce faulty and good blogs. What could be changing? Any pointers appreciated.

@MrBrian: I have now upgraded from 1.3.3 to 1.5.1 and creation of new blogs is working properly. (Took Donncha's advice in this thread to take things one step at a time.)

Glad you got it working :)