[Framework-Team] Re: PLIP125 (link integrity) part II - redirect-on-move ready for merge
optilude at gmx.net
Mon Dec 25 18:40:37 UTC 2006
>> 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.
More information about the Framework-Team