Don't break existing links!

[Michael Nahrath]

Lorenzo Cappelletti <l.cappelletti@mail.com> schrieb am 2002-12-06 10:50
Uhr:

>> The FAQ locally installed at /usr/local/share/gnupg/faq.html contains
>> several links to the www.gnupg.org website.
> 
> I tried to get in contact with FAQ author by writing to faq@gnupg.org,
> but he never replied.

That will not help anymore.

Invalidating <http://www.gnupg.org/docs.html> broke every single GPG
installation in the world.
You have to fix it on the server.  No way out!

How many years will it take until all current installations will be replaced
by at least GPG 1.3.2?
 
>> If it should be realy impossible to keep the old URL intact there needs to
>> be at least serverside redirections to the new resources.
> 
> When I spoke with Werner about my ideas on new site, he didn't argue
> against reorganizing the whole site, thus I moved files where I wanted
> to.

You are the web-designer so you have to know better.

Surgon: "I spoke with the patient before the operation and he didn't argue
against moving his ears to the abdomen"  ;-)

"Designing the web" does not only mean to make websites pretty but much more
to keep their functionality.
 
>> And if even that is impossible there should be more descriptive sites on
>> these URLs than the current 404 message.
> 
> I know of 3 methods for redirection:
> 
> 1. symbolic links
> 2. meta tag time-out redirection
> 3. web server configuration
> 
> Number 1 is very easy

.. and far the worst.

It would lead to have the same resources at multiple URLs.
This is very bad in terms of cachibility and searrch engine success.
It would irritate the users.

Additionally it would quite shurely break your system of language triggered
content negotiation.
 
> I'd prefer number two, because it also tells users that link has
> actually changed and warns them they should update their bookmark.

That one is very bad as well.

By principle you can't do redirections by
<meta http-equiv="RedirectPermanent" content="$new-URL">
because it doesn't get read before the page is already loaded.

Some people try 
<meta http-equiv="Refresh" content="$new-URL;$time">
This is a big mistake too.

Search engins would still get a "HTTP/1.1 200 OK" for the page and will
never forget it. 

If there is a redirection time set, users will either not recognize it at
all (I usually open Links in a background-Tab of my browser and start to
read them a while later) or the page will vanish at some uncontrollable
amount of time when they started reading the message.

> Werner says that number 2 is not portable across mirrors.

Mirroring will be a problem in any case if your content negotiation is based
on Caudium features ...

> Number 3 is server dependent.

The only good solution (for a bad problem).

Clients have to know, that the old site does no more exist.

There is a special response code to inform about this in http:

Have a look at 
<http://webtools.mozilla.org/web-sniffer/view.cgi?url=http%3A%2F%2Fwww.nahra
th.de%2Fmichael%2F&verbose=on> and try <http://www.nahrath.de/michael/> in
comparison. That is what it has to look like.

The server has to send a "301 (Removed Permanently)".

(I don't understand why this valuable service fails to work for
<http://www.gnupg.org/>).
 
> What do you think is the best?

1 and 2 are completely unadequate. 3 is the way to go.

There was another short hand solution. Stil bad but better than 1 or 2:

Create a static page <http://www.gnupg.org/docs.html> ( and for each other
URL of the old page) that informs the users of the reorganisation and links
to the new locations.
Include <meta name="ROBOTS" content="NOINDEX, FOLLOW">

I had to do this at <http://privat.schlund.de/B/BUH/> because I have no
rights to trigger real redirections on that server.

In any case the 404 (Page not found) page should be much more informative.
Read <http://www.cs.tut.fi/~jkorpela/www/404.html> to get the idea.
 
>> Second: 
>> Is it really neccesary to have souch strange URLs containing brackets?
>> Nobody uses this, there will be a lot of mistakes from not using what users
>> expect (you know Nielsen about this ...).
> 
> I totally agree with you, but Werner's running Caudium <http://caudium.net/>
> at the moment.  
> He told me once he's perplexed to keep on running that web server.
                       ^^^^^^^^^
Sorry, I don't understand what you are meaning. Are you shure that
"perplexed" is the right word?

> To me, I'm sure Caudium has got its own methods for doing what Apache
> does, but I don't have time right now to study its documentation.

If you stay with Caudium somebody will have to do.

Isn't there any other server (running the Apache we all know so well) that
could host the website?

The work to configure it for Apache has to be done anyway if mirroring
intended.
 
>> And something general about "moving" or "reorganizing" content away from its
>> original location:
>> <http://www.w3.org/Provider/Style/URI.html>
> 
> You're full of good links, aren't you?

They didn't come by themselves

<http://groups.google.com/groups?q=group:*authoring*+author:Nahrath> ;-)
 
> Old site was a 1-level deep framework where all files resided in root
> directory.  I know moving URLs around is a very bad practice, but I
> stronly believe that site needed a reorganization.

I see this and agree.

Doing it the Apache way (like Debian) would simply have meant

RedirectPermanent /docs.html http://www.gnupg.org/docs/

and all content negotiation would happen by the filename suffixes.
 
> PS: I cannot do anything till tonight. AArggghh!

Please excuse me for sounding a bit harsh.
Writing English is rather easy if it is about technics but expressing
suggestions in a polite and gentle way is much harder with the dictonary
in one's left hand.

Greeting, Michi