1. An attempted redirect if the path storage has something. This
basically means some string manipulation to decide which path was
"intended", and a BTree lookup to determine if there's something for
this path. If found, a 301 redirect is performed.
2. Otherwise, we look "up" the intended path and use traversal from
the portal root to check for an object that matches; this basically
covers the case when you wrote http://site.com/some/path/veiw or
http://site.com/some/psth (typo near the end of the URL) - it'll suggest
(in a listing) /some/path or /some in this case.
3. Also, we look at the end of the URL (last part after a slash) and
perform a catalog search for SearchableText=id. If that returns nothing,
we try again, with the second-to-last part of the URL, and so on until
we find something or the portal root. We don't try to do searches for
common method aliases or special things like 'index_html'.
Making 1, 2 and 3 optional might be nice. From the way you describe it
none of this is a per-user thing, so we can probably cache the action
1 (the redirect) is I guess the "core" functionality of avoiding broken
links. I don't see that much of a reason to make it optional (since it
ought not to have much of a performance overhead), but it would of
course not be so hard to do so.
2 and 3 (the suggestions given if there's a 404 and we can't redirect to
a "new" location for the intended path) are heuristic in nature and may
be a performance hit. I think it makes more sense to make a switch for this.
Framework-Team mailing list