ApacheWeek issue 198 included a very helpful link to an article that detailed one way of using FrontPage to administer a site otherwise served up by Apache: How to administer Win32 Apache web sites using FrontPage 2000. The author’s solution was to run Apache and Microsoft FrontPage Personal Server (MFPPS) both on the same NT machine, both sharing the same document root.

We faced a similar quandary on a site I administer. Some administrators responsible for Web content prefer to do so using FrontPage, including its CGI “bots,” but our main Web server is Apache running on SPARC Solaris.

For a variety of reasons, including my own bias, we have no desire to move our Web server to an NT machine. On top of that, I really, really don’t like the idea of installing the FrontPage extensions on a Unix box. It would make us completely dependent on Microsoft for security fixes, and I seriously doubt that providing timely updates for Unix code is high on Mr. Gate’s priority list.

At the same time, FrontPage is a useful tool for folks who don’t want to worry about HTML, CGI, and all the other acronyms that litter the world of web development. To support FrontPage, we run a secondary web server, this one running IIS on a Windows Server.

My solution du jour: proxying. The only adjustments that might need to be made to your Apache installation are enabling mod_rewrite and mod_proxy (but doesn’t everyone enable mod_rewrite?).

One of our administrators, for example, is working on a FrontPage “web” called somestuff. The files in question are available via http://ntbox/somestuff/. We didn’t want to confuse things by advertising a second Web server to the world, but we wanted to export its functionality in a transparent way.

What I’ve done is to add the following directives to our main server’s httpd.conf file:

# FrontPage proxies:
#
# Make stuff on ntbox available through the main web
# server. The silly RedirectMatch is necessary because
# IE won't automatically add a trailing slash to,
# e.g., http://www/somestuff -- which leaves the proxied
# pages full of slashless (and therefore broken) URLs.

RedirectMatch ^/somestuff$       http://www/somestuff/
RewriteRule   ^/somestuff/(.*)$  http://ntbox/somestuff/$1 [P]

The FrontPage stuff shows up via http://www/somestuff/, and everything seems to work pretty well. On the client side, FrontPage nicely uses relative URLs for all its internal HTML anchors, making proxying a fairly painless task.

Although it’s not absolutely necessary, the cleanest solution is to set up FrontPage “webs” on ntbox that do not have a corresponding namespace already in use on the main web server, e.g., to avoid http://ntbox/otherstuff/ if there’s already content accessible via http://www/otherstuff/. Just think of it as a RDBMS foreign-key integrity check…

This seems to me to be a win-win situation: FrontPage stays on Windows, where it belongs, but its pages can be accessed via our Unix server, ensuring that we don’t have to advertise two Web servers to the rest of the world.