Brion Vibber wrote:
Nick Jenkins wrote:
If I go to http://en.wikipedia.org/Tokyo (note the missing "/wiki"), I get a 404 page that contains a 5 second-client side refresh tag like so: <meta http-equiv="Refresh" content="5; URL=http://en.wikipedia.org/wiki/Tokyo">
Is there any chance we could follow the great example of the PHP folks, and immediately give the user what they really want (e.g. http://php.net/date , which instantly shows the user the content of the http://php.net/manual/en/function.date.php page) ?
I nixed that because then you've got scary unstable URLs being linked to. The URL system may change, potentially dramatically so, and they'll no longer work. (But I'm a bit of a stickler about stable URLs on articles.)
I can't say I agree to this hand-wavy argumentation. There is no reason to believe that any substantial amount of people would create links to the redirecting URL. My guess is that 95% of people go to Wikipedia, use the search function to find the article, and then copy & paste the URL. Another 4% construct the URL manually and then copy & paste the URL it redirected to. The remaining 1% are the wackos who construct URLs without actually trying them, and neither a 301 header nor the current 5-second soft redirect helps against those. Therefore, the 301 redirect is clearly more beneficial.
The PHP manual example is particularly dangerous because they don't even issue an HTTP redirect, it just spits the content right back. Bad for caching and for linking.
That, I agree with -- unless they have made clever arrangements to prevent themselves from needing to use those URLs for other purposes in future.
Timwi