Static URL Rant (was Re: vendors)

[Thomas Dowling]

> --On Wednesday, July 19, 2000 3:22 PM -0700 "Alma E. Garcia"
> <almag at mills.edu> wrote:
> > Also how have other libraries handled a change in IP address of
their
> > library server.
>
> Hopefully you have been using a name for your library server (e.g.
> "www.lib.mills.edu") rather than an IP address (e.g.
"123.456.789.012").


I know that Peter is a battle-scarred veteran of some major "Oops, our
IP changed, everyone revise your links" problems in his OhioLINK
days--he knows what he's talking about.  His message puts me in mind of
this document, which I have drafted countless times, usually after
tracking down dozens of nitwit changes to library URLs for Libweb.  I've
never posted it, because I always feared the people who need to see it
are exactly the ones who aren't reading this list.  I offer it now in
the hope that at least one librarian, facing systems administrators
intent on making such a change, can print it out, roll it up, and swat
them on the nose with it.


=============

Care and Feeding of the Library Home Page URL

Your IP address *will* change.
  - Always use a domain name.
  - www.lib.foo.edu, instead of 123.45.67.89

If you use a commercial ISP for web hosting, you
*will* change providers.
  - Avoid using URLs that show the ISP's domain name.
  - Register and set up your own domain name before
    ever going live.
  - http://www.foolibrary.org/ instead of
    http://www.gooey-cities.com/~foolibrary/

The machine you use for a server *will* change.
  - Have its name aliased to a name that is generic
    and function-related.
  - Use the alias in all references to the server.
  - Move the alias to new machines as necessary.
  - lib.fooville.state.us, instead of
    ultrix1.fooville.state.us.

The library's place in a larger organization's
structure *will* change.
  - Use URLs that do not reflect organizational
    hierarchies.
  - If org chart URLs are imposed by the organization,
    leave an alias or redirect from the old location.
  - http://www.foo.edu/library/ instead of
    http://www.foo.edu/computing_and_information/library/

Users *will* expect your URL to end at a directory name,
not a file name.
  - Give your logical home page the default file name
    for your web server.
  - Enable directory indexes for your site.
  - http://fooville.state.us/library/index.html (aka
    http://fooville.state.us/library/) instead of
    http://fooville.state.us/library/Welcome.html

  [Corollary to the above: You *will* eventually abandon
  non-default file names for home pages.  When you do,
  leave an alias or redirect from the old location.]

Users do *not* care about minor changes to departmental
names.
  - Do not change URLs to reflect such changes.
  - Keep the URL http://www.foo.edu/library/ even if the
    organization changes its name to "Libraries".  Make
    it an alias or a redirect to ".../libraries/" if
    necessary.

You *will* eventually use all lower-case URLs.
  - Do not create upper- or mixed-case URLs.
  - If you migrate from a mixed-case URL, leave an
    alias or redirect from the old location.
  - http://fooville.state.us/library/mainbranch.html
    instead of http://fooville.state.edu/Library/MainBranch.html

Come hell nor high water, do not allow your URLs to change any more
frequently than you change your circulation desk's phone number or
your street address.

When you do have to change a URL, you *will* receive hits at the old
location for at least two years.  For at least the first year, you
must leave a human-readable page at the old location informing people
of the change.  For at least another year, you must provide an HTTP
redirect with a Status 301 (Permanent Redirect) message so that both
human users and web indexers get the new page automatically.

To make this work, you *must* have access to someone with the
knowledge and systems permissions to handle DNS changes and web server
configurations, and you *must* work with a web server that handles
both aliases (two URLs pointing to the same resource) and true HTTP
redirects (requests for one URL return a server message with an HTTP
Location header pointing to another URL).  Meta tags and Javascript
location commands are not substitutes for true redirects.


=============

Thomas Dowling
OhioLINK - Ohio Library and Information Network
tdowling at ohiolink.edu