>* 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 <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
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
