Re: mod_dir DirectoryIndex vs. $r->uri() manipulation
>* David Pisoni <[EMAIL PROTECTED]> 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 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 I don't. Indeed, if I did, other parts of the system would fail terribly. My handler begins with : return undef unless ($r->is_main()) and proceeds as described above. Thanks, David
Re: mod_dir DirectoryIndex vs. $r->uri() manipulation
* David Pisoni <[EMAIL PROTECTED]> 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 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
mod_dir DirectoryIndex vs. $r->uri() manipulation
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 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 -- <[EMAIL PROTECTED]> "Education is a progressive discovery of our own ignorance." -Will Durant, historian (1885-1981)