Skip to content.

Personal tools
You are here: Home » Members » chrism's Home » Vanquishing the Virtual Host Monster

Vanquishing the Virtual Host Monster

I am victorious. I have vanquished the Virtual Host Monster.

repoze.zope2 was always meant to have a virtual hosting story separate than that of Zope 2's "Virtual Host Monster".. Tres and I struggled with this mightily in the early days of Repoze development, and I thought we had it licked. But alas, on Friday, I was in the #repoze IRC channel, talking with David Durham. He noticed that when he added lines to his Apache mod_wsgi Location configuration (as documented) like so, to enable virtual hosting:

  SetEnv HTTP_X_VHM_ROOT /plone

Nothing happened. So I went and looked at the code, and lo and behold it was BRIDGE OUT! We just had never finished the virtual hosting portion of repoze.zope2. Yikes, quite embarrassing, as I thought it had already been done. I had been documenting code that just didn't exist!

So today I went in and added it to repoze.zope2, and wound up releasing new versions of both repoze.zope2 (0.3.3) and repoze.vhm (0.5). It took a while for me to get virtual hosting working (I have four pages of notes to prove it; it took that much just to document what VHM was doing), but now you can use those headers in your Apache (or whatever) config to "turn on" virtual hosting when using repoze.zope2 with the repoze.vhm "xheaders" middleware in your WSGI pipeline. When running under this configuration, you can also now delete the virtual host monster from your Zope when using repoze.vhm if you need virtual hosting.

That's not very interesting, of course. What is interesting (to me, anyway) are these things:

  • The code to do virtual hosting in repoze.vhm and repoze.zope is about 140 lines of Python, all totaled. This replaces roughly 1000 lines of Python in SiteAccess' VirtualHostMonster. To be fair, some of this is UI code. But we don't need no stinking UI when we have a config file. On the other hand, why a VHM was ever configured via a persistent ZODB object is anybody's guess. I also must say that what VHM does to set the virtual root path is downright perverse. The repoze.vhm code is nowhere near as tricky.
  • The hideous syntax of URLs meant to be parsed by VirtualHostMonster turned out to be utterly unnecessary. It was so inscrutable it spawned a wizard to help people configure it. The repoze.vhm syntax uses HTTP headers to do the same job instead of encoding semantics in the URL, which makes it much nicer.

So before where you used to need to put in your Apache configuration something like:

  <VirtualHost *:80>
      RewriteEngine On
      RewriteRule ^/(.*)$1 [L,P]

You can (if you run under repoze.zope2 and repoze.vhm, proxying through to a Paste server) now replace that with:

  <VirtualHost *:80>
      RewriteEngine On
      RewriteRule ^/(.*)$1 [L,P]
      RequestHeader add X-Vhm-Host
      RequestHeader add X-Vhm-Root /plone

Or if you're running repoze.zope2 directly under Apache:

   <Location />
      WSGIPassAuthorization On
      SetEnv HTTP_X_VHM_HOST
      SetEnv HTTP_X_VHM_ROOT /plone

Damn, that felt good.

Created by chrism
Last modified 2009-02-25 05:47 PM


Nifty, lighty, swift and clean. That's the way things should be...great work


Why use X-VHM-* instead of X-Forwarded-*?

when repoze will land to official Zope/Plone?

when repoze will land to official Zope/Plone? It is great, works well, can do magic with WSGI, handles VH in the simplest way.

What are we waiting for? :)

the subject...

ian: why would I use X-Forwarded*? Is there some standard?

yurj: it needs a bit more baking time, but thereafter i think it will be a matter of how badly the masses want WSGI...

Fantastic stuff, Chris

This, I think, is one of the best cases so far of Repoze. The old way was baroque, clunky, and confusing to use. The new way makes sense, will be easier to alter (no monkey-patching Zope), is sensible outside our ghetto, etc.

Just great

Great. Clean syntax. Easy to explain.