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

2001-11-09 Thread Nikolaus Rath

* 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




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

2001-11-09 Thread David Pisoni

* 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




mod_dir DirectoryIndex vs. $r-uri() manipulation

2001-11-08 Thread David Pisoni

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 -- [EMAIL PROTECTED]

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