[Prev][Next][Index][Thread]

Re: Redirection in CL-HTTP

On Mon, 15 Jan 96 20:57:09 PST, Bob Kanefsky wrote:

> > The way to implement whole sale redirects would be to map the url table url::*
>url-table*
> > and apply export url with the appropriate arguments.
>
>That assumes that I've loaded the software that exports the URLs.  As a
>concrete example, suppose you wanted to redirect all requests for
>any URLs under
>        http://www1.ai.mit.edu/white-house-publications/
>to
>        http://www.whitehouse.gov/White_House/Publications/
>
>because you wanted to use www1.ai.mit.edu for development of
>experimental web software.  If URLs can only be redirected on an
>individual basis, then you'd have to keep all the old software loaded in
>your machine, or at least the part that exports all the URLs.  This
>means you'd need to keep your experimental software compatible with the
>old software so they could co-exist.  It would be nice if all it had to
>do was recognize that a particular URL subtree is now handled by a
>different machine, and forward those requests, without needing to be
>able to reconstruct the whole subtree.
>
>                                        --Kanef

The problem is, servers like httpd use the file system tree as a
default.  As you know, cl-http stores exported urls as objects off a
hash table.  This means that the server doesn't have to walk down a
tree to find a url.  It also means that the url can become a logical
specification, without necessarily representing a structure in memory.
For example, http://www.ai.mit.edu/foo/bar/index.html can exist
without there being an actual structure for /foo/ or /foo/bar/.
Therefor, walking down the url string to determine a subtree slows
down the access for every url on the server.  

Since you don't want to keep the old system around on the server,
there isn't anything initially there to generate the redirects from.
If the change is only temporary, a hack using the client or adding an
error-handler for document-not-found might be appropriate.  In the
case of a pernament change of host, lacking a URN infrastructure,
these changes necessarily rely on propogation.  People are going to
have to change their links.  When CERN moved it's web stuff to W3,
they exported messages containing a link to the new location for some
period of time.  As long as we rely on host names to locate resources,
this is what it comes down to.  Sorry I couldn't come up with a quick
fix, but this illustrates a problem with urls.

christopher vincent
cvince@ai.mit.edu
References: