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.
--
blu
"The advertising giveth and the EULA taketh away."
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
website-discuss mailing list
[email protected]
