[thelist] Redirection technique?

[Ken Schaefer]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Bob Easton" <bob at eleaston.com>
Subject: Re: [thelist] Redirection technique?


: Joshua Olson wrote:
: > Bob,
: > ...snipped...
: > URL rewriting may provide the simplest solution.  You could use it to
: > rewrite the requests to the old pages to the new pages (and thusly avoid
the
: > 301 altogether) or rewrite the request to the old pages to a single 301
: > proxy page that will redirect based on the URL.
: >
: > Google will have no issues with either solution.  Solution 1 is easier
to
: > implement but solution 2 provides a more permanent solution where
Google's
: > references will eventually be updated.
: > ...snipped...
: >
: >>- IIS hosting.
: > ...snipped...
: >
: > In IIS you can map any extension to any scripting engine.
: >  ...snipped...
:  >
: > Hopefully everything I mentioned above is within your current
experiences.
: > ...snipped...
: >
: Thanks for all the advice Joshua. Appreciated! The first few items on
: the list are already well underway and were mentioned only as
: perspective for the redirection question.
:
: The only place I need help is on the redirection technique. If the
: site were on an Apache server, a quick editing of a .htaccess file
: would do it.  But, it's on a shared hosting service where I have
: no access to IIS configuration parameters.  Now what?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You're going to need some kind of access to some kind of configuration
somewhere along the line. I'll try to layout the options that I can see. At
the moment the biggest problem that I can see that you need to overcome is
that .html extension is handled internally by IIS, not by any of the
external scripting engines, or ISAPI apps, so you don't automatically have
access to anything server-side to handle the URL redirection.

With IIS, each website has it's own configuration data. However this is all
stored in a central file. In IIS4/5 this is metabase.bin (a binary file), an
d in IIS6 it is metabase.xml (an XML file). A few critial server-side
settings are stored in the registry.

Hosting companies can provide adminstrative access to site owners, however
the level of access, and the method of access will differ from provider to
provider. Presumably, the less money you're paying, the less you'll have in
the way of options.

User accounts can be given site operator privileges, which would allow you
to make certain website configuration changes via the native IIS GUI tools
and/or the command line tools (adsutil.vbs etc). Alternatively, the hosting
company may provide you with some custom (typically web-based) admin tool
which in turn calls into the command line management tools or uses ADSI to
manipulate the metabase on your behalf.

All of the following options are going to require you to be able to make
some kind of website configuration change - either to add something to IIS
so that it does extra processing on your .html pages -or- changing what
handles .html pages (giving you access to a scripting engine, or ISAPI app
like ASP.Net).

Option 1) Write/Get hold of an URL Rewriting ISAPI filter and install it.
ISAPI filters can see the incoming request before IIS does, and modify the
incoming request. ISAPI filters can be installed on a site-by-site basis
However, because they can make fundamental differences to the way IIS
handles incoming requests, you probably need to talk to your hosting company
about getting this installed, especially if it's something you wrote
yourself. The ISAPI filter could do a lookup on a config file, and send back
an appropriate HTTP response to the client, or simple rewrite the request so
that IIS serves up the new page.

Option 2) Map .html to the aspnet.dll (assuming your hosting company offers
ASP.Net). This will give you access to either (and both) of HTTPModules and
HTTPHandlers. Which you choose to use is up to you. The difference can be
seen here:
http://www.15seconds.com/issue/020417.htm

Here is an example of a HTTPModule:
http://www.15seconds.com/issue/030522.htm

Which you use will depend on what you want to do (rewrite the path, or
redirect the user), and how confident you feel about your .Net skills.
However, both can be implemented without requiring any additional changes to
the server config. Instead you'd change either your web.config or your
global.asax file (neither of which requires any admin privileges per se)

Option 3) Map .html to asp.dll. This would give you a couple of options. You
could write a small bit of ASP code in each .html page to set the
appropriate response status (though this would be tedious for 750 pages), or
have each page do a lookup in a config file (or application array/dictionary
component).

Option 4) Make a configuration change (to IIS' custom errors settings), and
implement a central 404 file handler (which would allow you do away with the
individual, old, .html pages). The 404 handler would set the appropriate
response status (HTTP 301), and tell the client where the new resource can
be located. However, changing the IIS config so that the 404 handler is now
mapped to your custom page does require some kind of admin privileges on the
website in question. Your hosting company may already provide this via one
of their tools.

HTH

Cheers
Ken

Microsoft MVP - Windows Server (IIS)