Some of our servers need both PHP5 & Mono to run side-by-side so one of our guys listed the options:

<appSettings>
	<add key="MonoServerApacheStatus" value="true" />
</appSettings>

I eventually stopped brute forcing an attempt and intelligently looked at Apache2′s logs and found this wonderful line:

10.10.220.130 – - [10/Feb/2009:20:24:16 -0500] “GET /vrm/Create_Report.php?download=vrm_report_17_10-10-220-130.pdf HTTP/1.1″ 1 68856 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; …)”

Do you notice whats wrong? No? Look for the 1 after “HTTP/1.1″ and before the “68856″ – this is where the HTTP Status Code should be. Eh? What happened? Where’d my status go? The server-side looked like this:

if (file_exists($file)) {
	header('Content-Type', 'application/octet-stream', true);
	header('Content-Disposition', 'attachment/filename=' . $filename, true);
	header('Content-Length', filesize($file), true);
	header('Content-Description', 'File Transfer');
	readfile($file);
}

Any one notice the issue – header is being use inappropriately. The first argument should be the entire response header, the second argument is the option to override a matching header, and the third is the status code. “true” evaluates “1″ and thus the status of 1. You might ask as I am right now: Why is he divulging that he’s an idiot? Well folks it goes like this:

It’s 10:55PM and I’ve been programming since 8:30AM to meet a deadline. Things get missed and stupid mistakes happen. The above code worked on (IIS 6 + PHP5) but failed on (Apache2 + PHP5) – and this is one of the many reasons I hate PHP. The second argument should be a boolean and should SCREAM to the error log if you don’t match the type expected. Instead it says nothing, and leaves you to your madness.

Anyways, lets fix the code and go home!

	header('Content-Type: application/octet-stream', true, 200);
	header('Content-Disposition: attachment/filename=' . $filename, true);
	header('Content-Length: ' . filesize($file), true);
	header('Content-Description: File Transfer');

10.10.220.130 – - [10/Feb/2009:22:14:15 -0500] “GET /vrm/Create_Report.php?download=vrm_report_1_10-10-220-130.pdf HTTP/1.1″ 200 68856 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; …)”

Gah ;-0

Upon receipt of 204 IE appears to halt parsing as the XMLHttpRequest instance becomes corrupt and is no longer usable. Checking true/false against the instance works (and is false), but querying a method or variable from the instance produces an error.

var xhr = null;

try {
    // without try/catch IE throws error for no good reason
    xhr = new Ajax.Request(url, options);
} catch (exe) {
    /* will never fail on IE for 204 */
    console.error(exe);
}

// xhr is invalid for IE + POST + 204
if (xhr) {
    resp = xhr.transport;
} else if (/^post$/i.test(method) && this.isInternetExplorer()) {
    resp = this.FAKE_204_RESPONSE();
}

I vaguely remember reading on some site that IE fails on POST + 204 because it helps the browser short circuit and keep from redrawing the interface from a <form/> submission. This sort of makes sense because you can then upload/POST form data without having to redraw the page and still know if everything succeeded.

Either way, it is truly annoying. And the only reason I’m evening posting about this, other than education and helping myself remember, is that my original comments around the code above was vulgar. It happened to have been 3AM or so and my polite-o-meter wasn’t working well. It is now almost three years later and I believe some people have seen the original comments and didn’t find it appropriate – to which they are correct.

With that said – Internet Explorer has some weird quirks.