Coming from the .Net world, I have many projects I have to support that require my machine to have IIS (Internet Information Server) installed. Though Seaside is now my preferred development environment, and Apache my preferred web server, they need to all co-exist for me to do my job.

Seaside's web server isn't built for handling the kind of load Apache and IIS are capable of, and there's a lot of things a web site needs to serve up besides dynamic pages. Offloading all the static content, images, Javascript, CSS, HTML, zip files, and any other large downloads, is handled much better by a battle tested web server like Apache or IIS.

So the question arises, why use Apache at all, why not just use IIS? The answer is quite simple, IIS sucks for anything but using ASP.Net; it's not a pluggable web server like Apache is. When I first started using Seaside, I tried to get IIS to reverse proxy for me, it was a no go, I'd have to write code. Reverse proxying isn't something IIS can do out of the box, yet it's a simple configuration change in Apache. Apache has far more capabilities as a web server, than IIS does, or ever will. So I bit the bullet and learned how to use Apache, and I'm glad I did, it's an awesome web server.

Problem is, web servers want to run on port 80, so which one gets to own that? You'd think that you could easily run them both on port 80, and bind them to different IP addresses. In fact, this is possible, but it's a royal pain in the ass to accomplish, because IIS isn't well behaved and grabs onto whatever port it's running on, on every address on the machine, even when it isn't configured to do so, preventing Apache from being able to bind. There are instructions out there, on getting IIS to behave, but I gave up, it wasn't worth the effort.

Apache on the other hand, behaves perfectly, and does exactly what you tell it to do. Apache also supports reverse proxying out of the box. Given these options, I decide to run Apache as my primary web server on port 80, and run both IIS and Squeak on other ports and use Apache to simply reverse proxy to them both. This configuration works great. I went into my IIS sites in Internet Service Manager, changed each site to bind to port 81 instead. In Apache, you'll need to edit the httpd.conf (equivalent of Internet Service Manager) and bind to the local address on 80...

Listen 127.0.0.1:80

Uncomment the following (I think they already are, but don't recall)...

LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule rewrite_module modules/mod_rewrite.so

Enable virtual hosting...

NameVirtualHost *:80

And then create a virtual host, this is where all the magic happens

<VirtualHost *:80> ServerName localhost #bind hostname, could be onsmalltalk.com for example RewriteEngine On #enable url rewriting ProxyVia Block #enable reverse proxy ProxyPreserveHost On #make proxy rewrite urls in the output #for each .Net app, add a rewrite rule to intercept and proxy it RewriteRule ^/DotNetApp(.*)$ http://localhost:81/DotNetApp/$1 [P,L] #only allow Seaside rewrite rule to fire, when request doesn't match an existing file RewriteCond C:/Inetpub/websites/%{REQUEST_FILENAME} !-f #if no file was found, proxy the request to Seaside RewriteRule ^/(.*)$ http://localhost:3001/$1 [P,L] </VirtualHost>

Which looks much simpler without all the comments

<VirtualHost *:80> ServerName localhost RewriteEngine On ProxyVia Block ProxyPreserveHost On RewriteRule ^/DotNetApp(.*)$ http://localhost:81/DotNetApp/$1 [P,L] RewriteCond C:/Inetpub/websites/%{REQUEST_FILENAME} !-f RewriteRule ^/(.*)$ http://localhost:3001/$1 [P,L] </VirtualHost>

And that's it. Apache now acts as the front end, enabling the seamless appearance of running all the web servers on port 80. Visual Studio fires up and binds to .Net web sites without a hiccup, none the wiser that Apache is proxying the request. Mod rewrite now allows me to pick, based upon anything in the URL, which web server needs to handle the request. .Net sites run great, Apache handles all the static content, and Squeak only receives requests for dynamic page generation. Apache can also handle all the SSL requirements, certs, and leave Squeak blissfully unaware that the client is connecting through HTTPS. I use essentially the same setup in production.