Gabriel C Millerd wrote:
> On Fri, 14 Jun 2002, Geoffrey Young wrote:
>
>
>>that's odd. the above code essentially acts as though the user entered
>>/not_ok_page.html in their browser all by themselves. maybe I
>>incorrectly assumed that's what you were looking for?
>>
>>
> well the problem with a onsite url is that the handler would have to
> process that as well (unless i checked $r->uri for that specific uri. of
> failure or DECLINED aspect works 100% perfect. its the non-DECLINE that
> doesnt work
right. sorry.
that should have been
$r->uri('/not_ok_page.html')
if $not_ok;
return DECLINED;
you pretty much want to return DECLINED all the time. only return OK
if you alter $r->filename.
if you want to display not_ok_page.html no matter what (even if the
user enters it directly), then stick
return DECLINED if $r->uri =~ m!^/not_ok_page.html!i;
at the top of your trans handler (or something similar)
>
>
>>Apache only gives handlers one shot at translating the URI to a
>>
>>
> does this mean 'apache only gives one and only one shot shot a
> translating a url'
yes. the first handler (mod_perl or otherwise) to return OK wins, and
it's winner take all. that's why you return DECLINED - mod_perl will
run first (before any other Apache modules), alter the URI, then
Apache will move along as if nothing happened.
and don't forget that apache "errors" such as REDIRECT will terminate
translation as well :)
> or 'apache gives each handler one shot at translating a
> url'? i assumed that after 'PerlTransHandler ModuleName' is done
> mod_rewrite can still take a stab at the url.
it can if you return DECLINED no matter what. returning OK subverts
mod_rewrite as well as the default Apache translation engine.
does that help?
--Geoff
