You want to use client-side redirects? For the home page URL? With Zeus? And NSAPI? Are you mad??! Not yet…

Due to a - ahem - oversight in the development process, our friendly neighbourhood webslingers recently delivered a web application whose home page was located not under / but under /public. No problem, I confidently thought. I’ll use the frontend Zeus web server to alias the home page URL to the actual one…

First of all, forget the URL mapping feature. This maps URLs to physical directory paths in the filesystem. In this case, /public was a virtual URL handled by the application (via an NSAPI call). And URL mapping occurs after NSAPI calls.

We’ll use client-side redirects in the global htaccess file instead. But after several days spent trying every conceivable form of redirect command, including one sweaty morning two days before go-live (when an email highlighting a “potential showstopper” received a deafening silence from the culprits), there was almost blood on the keyboard. It seemed like every time I got it working, a minor tweak to the document root contents or the NSAPI handler config would break it again. Of course, this is a recipe for unstructured, panicked testing and unverified results so I apologise if some of the following is inaccurate.

For the record, this method works (because it’s working now on a corporate site): 1. Create a dummy (empty) index.html file in the document root on the web server. 2. In the htaccess file (remember to enable them in ZWS), use the following:
redirect permanent /index.html /public/

This will cause clients requesting http://website.com/ to be redirected to http://website.com/public/ (from where the request will be picked up by the NSAPI handler).

From this, I deduce that, because the NSAPI handler ignores ‘/’ as a URI, Zeus looks in the document root and finds a suitable default file (the dummy index). It then consults the htaccess file, which causes a 301 redirect and new Location: header to be returned to the client. The subsequent request is successfully processed by the NSAPI handler. The downside is, the user now sees (and bookmarks) a URL that doesn’t match the original one.

The following definitely don’t work: * Using / instead of /index.html in the Redirect directive - causes a redirection loop; * Using Location section directives to limit the redirected URL to / (either standard or a regex in LocationMatch) and thus avoid a loop - I don’t know why not; * Removing the dummy index file - causes a 403 access denied (if directory indexing is disabled); * Using the NSAPI redirect function - don’t go there.

Note: for Apache, the following will work:
<LocationMatch ^/$> Redirect / http://website.com/public/ </LocationMatch> It looks like this processing takes place before the other modules are called.

Alternative approach: Use a META refresh tag in the dummy index file.