ubuntu - Strange HTTP response headers being sent to Internet Explorer 8 only

So here's something I find puzzling.

I'm working on a Javascript that needs to parse XML data and I'm using jQuery's $.ajax to fetch and parse the data. It's working great everywhere except when I test with Internet Explorer 8 (it might be a problem on 7 and 9 too). On IE, I'm getting parse errors. I installed a console.log to check the HTTP headers. Here's what I get from Chrome on Windows XP and what I'm getting from IE --

Chrome:

Date: Sat, 09 Apr 2011 16:06:24 GMT
Connection: Keep-Alive
Content-Length: 2283
Last-Modified: Sat, 09 Apr 2011 15:59:12 GMT
Server: Apache/2.2.14 (Ubuntu)
ETag: "48048-8eb-4a07e6c693400"
Content-Type: application/xml
Accept-Ranges: bytes

Keep-Alive: timeout=15, max=97

IE8:

LOG: ETag: "48048-8eb-4a07d7a3cbe40"
Keep-Alive: timeout=15, max=97
Content-Type: text/html
Content-Length: 2283
Last-Modified: Sat, 09 Apr 2011 14:51:29 GMT

This is a sample of what the xml document looks like:

    
        name
        message
        avatar

    
    
        name
        message
        avatar
    

I checked the MIME configuring for my Apache server and it is set to send xml files as 'application/xml'. So it's strangely sending a content-type of 'application/xml' to Chrome, but IE gets content-type of 'text/html'.

So I built a simple PHP script:

header('Content-type: application/xml; charset=UTF-8');
echo '';
?>

    
        name

        message
        avatar
    
    
        name
        message
        avatar
    

When I change the Javascript to retrieve the PHP instead of the XML file, I get these response headers --

Chrome with PHP:

Date: Sat, 09 Apr 2011 16:10:39 GMT
X-Powered-By: PHP/5.2.10-2ubuntu6.7
Connection: Keep-Alive
Content-Length: 2102
Server: Apache/2.2.14 (Ubuntu)

Content-Type: application/xml; charset=UTF-8
Keep-Alive: timeout=15, max=97

IE with PHP:

LOG: X-Powered-By: PHP/5.2.10-2ubuntu6.7
Content-Length: 2102
Keep-Alive: timeout=15, max=100
Content-Type: application/xml; charset=UTF-8

More strangeness I just discovered. I put an

AddType application/xml tweets

into my directives for that virtual server. When I then fetch my XML document with the .tweets extension, IE does get the correct content-type in the header! In fact, the header looks more like the Chrome version --

Chrome with .tweets file:

Connection: Keep-Alive
Content-Length: 2102
Last-Modified: Sat, 09 Apr 2011 16:33:46 GMT
Server: Apache/2.2.14 (Ubuntu)
ETag: "48048-836-4a07ee807ee80"
Content-Type: application/xml
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100

IE with .tweets file:

LOG: Date: Sat, 09 Apr 2011 16:38:56 GMT
Server: Apache/2.2.14 (Ubuntu)
Last-Modified: Sat, 09 Apr 2011 16:33:46 GMT
ETag: "48048-836-4a07ee807ee80"
Accept-Ranges: bytes
Content-Length: 2102
Keep-Alive: timeout=15, max=100

Connection: Keep-Alive
Content-Type: application/xml

So from what I can tell, with my limited Apache knowledge, it seems like the raw XML file is getting sent without the right content-type only to IE, even though I have it configured to send 'application/xml'. Chrome is receiving the right content-type. When I use PHP, Apache seems to be following my wishes and sending 'application/xml' because that is what I stamped it as in the script. Is it also strange that IE doesn't have all the same headers as Chrome? "Server" is missing for instance. When I add a custom extension of .tweets, configured to use application/xml, I also get the correct content-type.

So what could possibly be getting in the way and changing 'application/xml' to 'text/html' only for Internet Explorer? I'd hate to have to rely on my workarounds. I thought of mod-deflate, but I disabled it and the results are the same.

Any ideas?

(PS - the XML I'm including is just a sample, so the content-lengths don't match up

Answer

So I think I figured it out.

It appears that IE caches the AJAX GET data in such a way that it is hard (impossible?) to clear it out. Maybe I had the xml configured as text/xml at some point, but I don't think so. Basically, IE continued to use the cached results for that XML file over the actual server results. That also explains why the HTTP headers looked so odd (no server information for instance). Or it's possible that the cache is always producing text/html (I gave up further tests).

My solution:
I added a '?avoidcache=' + a timestamp to the end of the URL in the GET request. Now IE gets the proper HTTP headers that I set on the server.

Wow do I hate Internet Explorer. How many development hours are wasted creating workarounds for it's horrible behavior?