mod_dir DirectoryIndex vs. $r->uri() manipulation

[David Pisoni <da...@cnation.com>]

Hello again modperlers,

I am using perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26.

I have an interesting problem which maybe someone could shed some light on :

I have an early phase handler (can be done as either a PerlPostReadRequestHandler or a PerlTransHandler) which manipulates the request URI.  The purpose of the handler is to strip out the first segment of the URI path and employ that as a "user type" string.  I presently have it as a TransHandler which returns DECLINED, expecting Apache to continue URI translation based on the new URI setting.  For almost all types of URIs this functionality is working: it works for files in the DocumentRoot, it works for PerlHandlers declared in <Location> blocks, and it works for Alias mapped paths. Only one thing breaks...

The one URI type which isn't resolved correctly is DirectoryIndex-resolved paths.  If mod_autoindex is on, then an AutoIndex directory listing is displayed.  If mod_autoindex is off, a "NOT FOUND" error is displayed.  If I access the same directory without the URI manipulation (and without the extra "user type" segment), the DirectoryIndex-specified file is served as expected.

I thought to myself, maybe the mod_dir resolution wants to be before any declared PerlTransHandler (even though mod_autoindex comes after) so I tried moving my handler to a PostReadRequestHandler.  Same effect though -- something is short-circuiting the DirectoryIndex function of mod_dir.

Anyone else encounter this?  Any ideas how to resolve?

Thanks,
-- 
David Pisoni -- <da...@cnation.com>

"Education is a progressive discovery of our own ignorance."
-Will Durant, historian (1885-1981)

Re: mod_dir DirectoryIndex vs. $r->uri() manipulation

[Nikolaus Rath <Ni...@rath.org>]

* David Pisoni <da...@cnation.com> wrote:
> Hello again modperlers,
> 
> I am using perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26.
> 
> I have an interesting problem which maybe someone could shed some
> light on :
> 
> I have an early phase handler (can be done as either a
> PerlPostReadRequestHandler or a PerlTransHandler) which manipulates
> the request URI.  The purpose of the handler is to strip out the
> first segment of the URI path and employ that as a "user type"
> string.  I presently have it as a TransHandler which returns
> DECLINED, expecting Apache to continue URI translation based on the
> new URI setting.  For almost all types of URIs this functionality is
> working: it works for files in the DocumentRoot, it works for
> PerlHandlers declared in <Location> blocks, and it works for Alias
> mapped paths. Only one thing breaks...
> 
> The one URI type which isn't resolved correctly is
> DirectoryIndex-resolved paths.  If mod_autoindex is on, then an
> AutoIndex directory listing is displayed.  If mod_autoindex is off,
> a "NOT FOUND" error is displayed.  If I access the same directory
> without the URI manipulation (and without the extra "user type"
> segment), the DirectoryIndex-specified file is served as expected.
> 
> I thought to myself, maybe the mod_dir resolution wants to be before
> any declared PerlTransHandler (even though mod_autoindex comes
> after) so I tried moving my handler to a PostReadRequestHandler.
> Same effect though -- something is short-circuiting the
> DirectoryIndex function of mod_dir.
> 
> Anyone else encounter this?  Any ideas how to resolve?

Don't try to strip the uri in sub requests ($r->is_main()).

   --Nikolaus