[Framework-Team] Re: PLIP125 (link integrity) part II - redirect-on-move ready for merge

Martin Aspeli optilude at gmx.net
Mon Dec 25 18:40:37 UTC 2006

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
> taken?

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 mailing list