You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@hyperreal.org> on 1997/07/14 23:45:47 UTC
autoindex bug
It appears that if the Configuration file includes mod_autoindex *after*
mod_dir (and thus the order in modules.c is different), the output of any
request to a directory is garbled. I.e. the DirectoryIndex is ignored, and
the table of files has "0K" for the file size (that's zero-K) and doesn't
know what file types they are. Since they both use the same stages in the
API, it's not obvious where the bug is being triggered...
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Why not?" - TL brian@organic.com - hyperreal.org - apache.org
Re: autoindex bug
Posted by Dean Gaudet <dg...@arctic.org>.
Fixed... one of the two has to add a trailing / to r->filename. Now both
of them do it, so you should be able to use either alone or together. But
it doesn't make much sense to place mod_autoindex after mod_dir... 'cause
it would always generate an index if Options Index was set.
Dean
On Mon, 14 Jul 1997, Brian Behlendorf wrote:
> It appears that if the Configuration file includes mod_autoindex *after*
> mod_dir (and thus the order in modules.c is different), the output of any
> request to a directory is garbled. I.e. the DirectoryIndex is ignored, and
> the table of files has "0K" for the file size (that's zero-K) and doesn't
> know what file types they are. Since they both use the same stages in the
> API, it's not obvious where the bug is being triggered...
>
> Brian
>
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> "Why not?" - TL brian@organic.com - hyperreal.org - apache.org
>
Re: autoindex bug
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> It appears that if the Configuration file includes mod_autoindex *after*
> mod_dir (and thus the order in modules.c is different), the output of any
> request to a directory is garbled. I.e. the DirectoryIndex is ignored, and
> the table of files has "0K" for the file size (that's zero-K) and doesn't
> know what file types they are. Since they both use the same stages in the
> API, it's not obvious where the bug is being triggered...
I noticed this as well, sort of. I didn't get garbled output, autoindex
just didn't work. Switching the order fixed things.
-Rasmus