Hi Wiggy,

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

Reply via email to