Hi,
Thanks everyone for your time to make comments and suggestions. We know
people are concerned and believe the concerns are valid and we're
looking at options.
Regards,
Michelle
On 08/13/09 07:51, Brian Utterback wrote:
Hugh McIntyre wrote:
Elaine Ashton wrote:
I AM thinking of the end users as if we would do a URI rewrite for
10-20,000 pages, this would entail the server scanning /every/ rule
to match against before finally serving up the page. In the battle
of glacial server vs. broken link on a zippy server, the zippy
server wins.
You could obviously do a database lookup to go from old->new, rather
than a log list of rewrite rules, for performance. For example in
mod_perl. The database of old->new conversion mappings gets created
once when the site is migrated.
And if the URL space is organized appropriately, you can make sure
that only old pages go through this database lookup, for example a
top level rule that this only kicks in for pages starting with /os/
(and not using this prefix for the new site).
If any of the new pages go away in future then you get a 404 response
to the mapped page then - nobody is saying this can't happen any more
then there are a subset of broken links in the past - but only for
the smaller subset of pages that move, and only in future. Some
people have bookmarks and other existing links to pages...
And it wouldn't have to be forever, anyway. If you specify the
redirects via "permanent relocation", then after a while many of the
sources will note the move and update bookmarks, etc. Then a little
time later, you examine the logs and see which pages are still getting
traffic to the old URL and which do not. It is likely that the number
of URLS still getting traffic will be much smaller than the total
number of pages, so you whittle the redirect database down to just
those and go back to your plan A for the rest. I bet the resulting
database will be much smaller than the original one was.
_______________________________________________
website-discuss mailing list
[email protected]
