tag:blogger.com,1999:blog-3524127.post4462961748455894869..comments2023-10-27T01:20:31.352-06:00Comments on IdeaJoy: URLs Should Be ForeverUnknownnoreply@blogger.comBlogger1125tag:blogger.com,1999:blog-3524127.post-79738896081932903232008-11-29T19:15:00.000-07:002008-11-29T19:15:00.000-07:00Yeah, in an ideal world there would be no dead lin...Yeah, in an ideal world there would be no dead links. We deal with this quite often when we migrate a client from some archaic and poorly designed system (ex. Kintera) that has URLs like:<BR/><BR/>http://example.com/site/c.mwL5KkN0LvH/b.1406015/k.867B<BR/>/Content_Search/apps/s/search.asp<BR/><BR/>or <BR/><BR/>http://example.com/atf/cf/{39FAE17B-8AA5-4B26-934C-710DD031608<BR/>8}/flashobject.swf<BR/><BR/>There's obviously no easy way to reverse engineer what defines those URLs. <BR/><BR/>On the new site we'll setup URLs like:<BR/><BR/>http://example.com/search<BR/><BR/>or <BR/><BR/>http://example.com/files/flashobject.swf<BR/><BR/>We'll tell the client: this is the cost of creating an old->new map of URLs on the new site (both developer time and performance cost (having a billion rewrite rules noticeably slows things down)). And usually the client says "screw it". Sometimes we'll setup a nice 404 page that auto-searches for what the user might have been trying to get to, but this has performance implications as well (it means doing intensive searches in response to every bot searching for cgi-bin/some-known-exploit ). <BR/><BR/>Needless to say, the real world often makes compromises.Anonymoushttps://www.blogger.com/profile/03573114338095369048noreply@blogger.com