| Subject: | DirectoryIndex Redirect Loop |
Using 1.6.2 of AxKit, I've run into a redirect loop when trying to access the root of a directory handled by AxKit. This happens both under Redhat 9 and Solaris 8, both with perl 5.8.0.
Using this apache config, I can reproduce the error on the above mentioned platforms, but on Redhat 9 with 1.6.0 it works fine:
Alias /docs /ids/tools/DOCS/xml
<Directory "/ids/tools/DOCS/xml">
Options +All
DirectoryIndex index.xml index.html
SetHandler perl-script
PerlHandler AxKit
AddHandler axkit .xml .xsp
AxGzipOutput On
AxDebugLevel 10
AxAddXSPTaglib AxKit::XSP::Util
AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT
AxAddStyleMap application/x-xsp Apache::AxKit::Language::XSP
</Directory>
The corresponding error (except a few more pages of this loop) is here:
==> /www/logs/orpheus/access_log <==
127.0.0.1 - - [26/Nov/2003:10:06:44 -0800] "GET /docs HTTP/1.1" 302 281
127.0.0.1 - - [26/Nov/2003:10:06:44 -0800] "GET /docs/ HTTP/1.1" 302 282
127.0.0.1 - - [26/Nov/2003:10:06:44 -0800] "GET /docs// HTTP/1.1" 302 283
127.0.0.1 - - [26/Nov/2003:10:06:44 -0800] "GET /docs/// HTTP/1.1" 302 284
127.0.0.1 - - [26/Nov/2003:10:06:44 -0800] "GET /docs//// HTTP/1.1" 302 285
==> /www/logs/orpheus/error_log <==
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] handler called for /docs
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] Content Provider Override: Apache::AxKit::Provider::File
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] decoding from UTF-8
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] [req] File Provider given $r: /ids/tools/DOCS/xml
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] checking if we process this resource
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] '/ids/tools/DOCS/xml' is a directory
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] handler called for /docs/
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] Content Provider Override: Apache::AxKit::Provider::File
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] decoding from UTF-8
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] [req] File Provider given $r: /ids/tools/DOCS/xml
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] checking if we process this resource
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] '/ids/tools/DOCS/xml' is a directory
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] handler called for /docs//
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] Content Provider Override: Apache::AxKit::Provider::File
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] decoding from UTF-8
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] [req] File Provider given $r: /ids/tools/DOCS/xml
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] checking if we process this resource
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] '/ids/tools/DOCS/xml' is a directory
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] handler called for /docs///
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] Content Provider Override: Apache::AxKit::Provider::File
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] decoding from UTF-8
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] [req] File Provider given $r: /ids/tools/DOCS/xml
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] checking if we process this resource
[Wed Nov 26 10:06:44 2003] [warn] [client 127.0.0.1] [AxKit] '/ids/tools/DOCS/xml' is a directory
BTW, this happens regardless whether there is a DirectoryIndex directive or not.
If the same <Directoy> directive is used and /ids/toolds/DOCS/xml is made the DocumentRoot, the error manifests itsself by returning a 302 Found instead with a URL of http:/// as the place the document has moved to.
Finally, the contents of the directory do not seem to matter. The exmaple can be modified to point to /tmp and the results are the same.
I can downgrade to 1.6.0 to avoid this, but prefer not to, since another bug exists there that was fixed in 1.6.2, but as it stands, I cannot use 1.6.2 for production.