Viraj's Weblog

Today I struggled to get Apache setup as a reverse proxy. The idea is you have a server on your intranet, say internal.server.com, that you want to be able to access from the Internet as, say external.server.com.

A reverse proxy is setup on external.server.com, and HTTP requests are proxied to the internal server. This allows you to wrap SSL over the connection, or even use separate authentication on the external server. There are issues though. The HTTP headers need to be rewritten from external.server.com to internal.server.com for requests, and vice versa for responses. This can be done with mod_rewrite. Additionally, you would need to rewrite the HTML to change any links. That's where it gets tricky.

The only thing I could find was mod_proxy_html. There was no Debian package, and I had alot of trouble trying to get this to compile with Apache 1.3. So I went ahead and grabbed the Apache 2 Debian packages, which had a pre-built mod_proxy_html. I wanted to wrap SSL on the connection, but found that the SSL configuration is not setup by default in Debian. I found this blog which had alot of useful info for setting up SSL with Apache 2 on Debian quickly.

Next I followed the tutorial to setup the reverse proxy. After much trial and error it was working mostly, but didn't rewrite meta-equiv refresh stuff properly, even with the proper mod_proxy_html options to supposedly make it do that. Ok, not a big deal. Then while testing an internal Twiki site, I saw that the html got fucked up on certain pages, with random >'s and such. Not a good sign. I was ready to ditch this solution.

Pete pointed me to CGIProxy, which I figured would give a try. This is basically a Perl CGI script that acts as a proxy. To my surprise, it was simple to setup, and just works flawlessly. I was concerned that the last update to the script was in 2002, but it looks like it is stable. I can still wrap SSL over it, or do authentication, etc. I definitely recommend this over the Apache config hackery.

The idea of 'workflow' is being thrown around alot at work. The hope is to streamline business processes.

First of all I think this whole concept of workflow is more complex than it needs to be. One of the least 'vague' packages I found was Openflow, which is based on Zope. I've been doing some reading on Zope and I think it's a very cool web framework. But this Openflow thing has shitty documentation. At least put some howto up to help people try your code. There I noticed links to the Workflow Management Coalition which has some sort of standard out. There is a TALES language specification for defining workflows. Ugh, it's all ripe for picking by commercial packages.

Then I found another package called CMSOpenflow which looks based on Openflow, but requires Zope, Plone, CMS, blah blah. It's still very cryptic to me, and why am I going to install all this stuff for something I have no understanding of.

I thought the simplest workflow, at least that I could understand, was an approval system. There is some purchase request, someone needs to look over it and approve it. Simple.

Pete over at Mako pointed me to Twiki, so I started looking for plugins. I found ApprovalPlugin, which is probably the clearest explanation of a workflow implementation I've read. So I'm reading about it and notice the author. Wow, it's an old co-worker from Z-Kat. Nice work!

I'm still not very excited about this. It's hard to be excited about business processes.