The Netcraft February 2008 Web Server Survey says:

Unusually, America Online’s open source AOLserver sees tremendous growth, jumping from 35 thousand to 105 thousand sites in just one month. AOLserver is a multithreaded, Tcl-enabled web server which can be used for large scale, dynamic web sites, but has not seen the release of a new version since 2006. The majority of the new sites served by AOLserver are hosted in Poland.

This isn’t going to make any headlines, but for all those doubters out there who keep wondering who actually uses AOLserver, check out that growth.

The sad thing is, we could easily game the Netcraft survey by doing a few simple things:

1. Register to become an ICANN accredited domain registrar.
2. Offer domain registration at-cost, to offer the lowest possible prices to get customers.
3. Offer free web domain parking or static file only hosting, all on AOLserver.

The costs involved would be around $10K for the first year, plus the cost of the actual AOLserver hosting, plus the $70K working capital in reserve to meet ICANN’s requirements. This could all be set up on Amazon EC2/S3 to avoid having to provision real hardware as the customer demand grows.

Of course, what would be the point? Would having more significant numbers in the Netcraft surveys give AOLserver more credibility? I sure hope not–that would be foolish.

(via Mark Mcgaha)

In the “scratch your own itch” department, I decided to get Wordpress working under AOLserver. Wordpress is written in PHP, and while AOLserver can load PHP as a module, it doesn’t play nice when you configure AOLserver with multiple virtual servers. The other option, running PHP as CGI using nscgi and php-cgi, does work for the most part. However, there were a few issues I ran into that required changes to nscgi, which I’ll outline below.

Adding REQUEST_URI to CGI env. variables

PHP expects an additional environment variable, REQUEST_URI, to be included on CGI requests. Of course, this isn’t part of the CGI/1.1 specification. Basically, PHP expects REQUEST_URI to contain the Request-URI (from the HTTP/1.1 specification, see section 5.1.2). So, I added this in.

Mapping URLs to CGI with ns_register_cgi

In order to map an URL to be handled by nscgi, you previously had to make the change in your config .tcl and restart AOLserver. One of the great things about AOLserver is the fact that you can modify some settings at runtime, without a restart. So, I looked at whether it would be possible to add additional mappings at runtime, and it appears that under the hood, nscgi also uses the Ns_RegisterRequest C API which is supposed to be safe to execute at runtime. So, I added a new Tcl command, ns_register_cgi, which is now part of nscgi. It is just a wrapper around CgiRegister, and thus takes the same argument.

For example, if you wanted to map all requests to “/foo” (including “/foo/bar“) to a PHP script “/var/www/myfoo.php“, you would use something like this:

foreach method {GET POST HEAD} {
    ns_register_cgi "$method /foo /var/www/myfoo.php"
}

This maps GET, POST and HEAD requests to URLs starting with “/foo” to the script specified.

Caveat: It is currently possible to load the nscgi module multiple times in the same AOLserver process, for each virtual server. It is also possible to load it multiple times for the same virtual server. I’m not sure why anyone would do that, but it’s possible. In that circumstance, the behavior of ns_register_cgi is undefined–as in, I haven’t tested it. It may or may not work correctly. If you run such a configuration, where nscgi is loaded multiple times in the same virtual server, please test this carefully and share your findings. Thanks.

Where’s the code?

I’ve commited the changes to SourceForge CVS, both in HEAD (rev 1.33, diff) and the aolserver_v40_bp branch (rev 1.23.2.4, diff).

Tags: AOLserver, PHP, CGI

I have way too many saved emails in my inbox, over 5,500 when I started writing this. Of those, over 2,200 are AOLserver-related. I haven’t them filed away yet because they represent a loosely organized “to do” list for me. But, with so many open items, it’s a daunting task to go pluck out interesting things to work on, so I’ve mostly avoided doing it and haven’t gotten anything done.

I’ve wanted to get my inbox back down to a manageable size for a while, so I’m going to go through it and create a high-level summary of the open issues so I can finally file all those old emails (dating back to 2004, some of them) away.

On with the list …

• Making everything binary safe and aware (i.e., nsdb, ns_set, etc.)
• Review nsodbc, the ODBC nsdb driver, make sure it works on Win32 as well as with unixODBC
• Review nsperm, the stock HTTP authentication implementation that comes with AOLserver out-of-the-box
• Clean up the nsmysql driver, properly license it with the AOLserver Public License (or perhaps some other license) so it can be included in Debian, etc.
• Fix the nslog hack to handle X-Forwarded-For headers, make it do the right things
• Commit the changes I’ve been sitting on for nsopenssl and tag a new release of it
• Review Eric Lorenzo’s tclprof (OpenACS thread here), get it checked into CVS, consider Jamie Rasmussen’s suggestions for changes, and rationalize it with the existing nsprofile module
• Start on a manuscript for an AOLserver book

… and this is only a partial list. I still have plenty of emails to go through in my inbox–I’m only down to 5,100 messages, now.

Of course, if you’d like to help out by tackling any of the items on the above list, don’t let me stop you–go right ahead! If you want to know more about anything in particular, just ask.

Tags: AOLserver

Here are the slides for my presentation, Server-Side JavaScript with jQuery and AOLserver, that I gave at jQueryCamp07 today.

• Server-Side JavaScript with jQuery and AOLserver [pdf]

Tags: JavaScript, jQuery, AOLserver, presentation, slides

It’s not fully baked yet, but let me take a break from coding to … squee! You have no idea how excited I am right now.

Back in February, I blogged about nsjsapi, an AOLserver module that makes the SpiderMonkey JavaScript interpreter (written in C) available to Tcl. Then, in July, John Resig blogged about env.js, which he used to load jQuery under the Rhino JavaScript interpreter (written in Java). env.js is neat because it’s a JavaScript implementation of a basic browser and DOM environment which isn’t provided by either SpiderMonkey or Rhino.

However, env.js assumes its running under Rhino, or at least has all the java.* and javax.* and org.w3c.dom.* APIs available, so it doesn’t completely work under SpiderMonkey. So, I’ve set out to implement all those missing bits in JavaScript, in nsjsapi.js. (Yes, I know I’m crazy …)

After a few days of furious coding and much head-desking, I’ve gotten far enough that I can do this from an AOLserver control port:

nscp 1> set js [js create]
js0x88e0838
nscp 2> js load $js /home/dossy/htdocs/js/nsjsapi.js
undefined
nscp 3> js load $js /home/dossy/htdocs/js/env.js
undefined
nscp 4> js load $js /home/dossy/htdocs/js/jquery-1.2.1.js
undefined
nscp 5> js eval $js {jQuery.fn.toString = DOMNodeList.prototype.toString; true;}
true
nscp 6> js eval $js {window.location = 'test/index.html';}
undefined
nscp 7> js eval $js {$('body').html()}
<div><span id='foo'>This is a test.</span></div>
nscp 8> js eval $js {$('div').append('<span>Hello world!</span>')}
[ <div> ]
nscp 9> js eval $js {$('body').html()}
<div><span id='foo'>This is a test.</span><span>Hello world!</span></div>

I guess this doesn’t seem like much of an accomplishment, but it’s a huge first step towards being able to do actual JS-based server-side web development under AOLserver.

I want to iron out a strange crash bug when the JS interp. is destroyed via [js destroy], and complete the file I/O stub that isn’t finished yet, then check in nsjsapi.js. I plan to get this done in time for my talk at jQueryCamp07 this weekend.

Tags: AOLserver, jQuery, JavaScript, nsjsapi