Mono + SCGI

Over a year ago I started a SCGI daemon for Mono (scgi-mono-server). For those who don’t know, the “SCGI protocol is a replacement for the Common Gateway Interface (CGI) protocol. It is a standard for applications to interface with HTTP servers. It is similar to FastCGI but is designed to be easier to implement”.I stopped all development shortly after I started because lighttpd (the web server I cared about) required a very small patch to be useful. Having supplied the patch I waited around for it to be rolled into a release (1.4.20) and then waited for it to be picked up by Ubuntu, but it still hasn’t. So what brought it back to life? A silly bug:

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

  • Pull mono & mod-mono 1.9.1 back-ports from a PPA (
  • Patch and rebuild mod-mono 1.2.5 ourselves
  • Switch to FastCGI for PHP5, so we can use apache2-mpm-worker for mod-mono-server
  • Switch from Apache to lighttpd (and rebuild with our patch)
  • Switch from Apache + mod-mono to Apache + FastCGI or SCGI (requires patching lighttpd)
  • Switch from Apache + mod-mono to Apache + mod_proxy for XSP

Given our growing dislike for Apache & appreciation for lighttpd we decided on a phased approach:

  • Switch PHP5 to Apache + FastCGI
  • Switch Mono to Apache + SCGI
  • Run for a while (make sure everything works well)
  • Switch from Apache to lighttpd

We choose SCGI for Mono over FastCGI because:

  • FastCGI requires a lot of chatter between the client & server
  • Great incentive to finally give the server to Mono

With our approach in mind I started working on scgi-mono-server again, but with a new target – Apache. This shouldn’t have been very hard given that mod_scgi is provided by Quixote, but there were a few stumbling blocks. Apache, for whatever reason, has decided to break the SCGI specification (in my eyes). As stated in the Protocol: “[t]he format of the response is not specified” – meaning whatever the SCGI server sends back to the client (Apache, lighttpd, etc) should go back to the originator (web browser). Apache however, does not honor this.

The first line of any HTTP response (AFAIK) should be it’s Status Line:

HTTP/1.1 200 OK.

Apache’s mod_scgi requires that all lines until the body have a colon so that is can parse the header and update it’s internal data model. Therefore, our first line now has to be replaced by:

Status: 200 OK

Thankfully the Example section of the protocol showed me how to fix the issue. I’m tempted to patch Apache/mod_scgi but I’m a bit worried about how many SCGI servers require this broken code. So for now I’ve added a configuration option that can be put inside ASP.NET’s web.config to control the hack:

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

I’ll be submitting the server back to Mono with some documentation after it goes through some solid developer testing on our side – so I hope someone enjoys!

PHP Annoyances: header()

Earlier today, and yesterday in fact, I was successfully downloading generated PDF’s from a FLEX application from an Apache2 server via mod_php5. Tonight however, it kept failing with an IOErrorEvent #2038. There’s lots of fun references to this issue like this one. Sadly downloading via FileReference doesn’t trigger the HTTPStatusEvent event, so I can’t lie to FLEX.

I eventually stopped brute forcing an attempt and intelligently looked at Apache2′s logs and found this wonderful line: – - [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');

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

Internet Explorer Quirks: 204

A long time ago when I first started doing a lot of REST + Ajax developement I hit a really strange issue. Apparently, if your server returns a HTTP Status code of 204 in response to a POST method IE partially blows up. Part of this has to do with IE requiring try/catch blocks around code that could be devastating – like XMLHttpRequest.send()? And part of it has to do with IE not parsing a 204 response.

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 */

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