DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8045>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8045
Apache 2.0.35 compile without mod_autoindex
------- Additional Comments From wrowe@apache.org 2002-04-27 04:08 -------
Action httpd/unix-directory /directory-not-allowed
Redirect 403 /directory-not-allowed
might be a gross, dirty hack, but it just might work for the moment.
I suppose the default-handler should be taught to recognize and fail
httpd/unix-directory requests with a 404. My only concern is that
this is -not- a 404, that level of the heirarchy -is- found, but
can't be processed in any meaningful way. Implies a 401 or 403.
The processing schema's changed enough that you tickled this oversight.
In fact, we are erroring out far more often (even in late 1.3.x builds)
due to the possibility of one module being tricked into failure, and
having another module pick up the request. E.g. some folks used
multiview matching on index documents, but those could (in some very
bizare and tangled circumstances) be evaded, and autoindex was picking
up the slack when the admin didn't intend for that to happen. We now
avoid Not Found as a 'catch all' if resources exist, otherwise such
potentials will always exist.
Thanks for the report, and let us know about the gross hack!
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8045>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8045
Apache 2.0.35 compile without mod_autoindex
------- Additional Comments From wrowe@apache.org 2002-04-27 04:08 -------
Action httpd/unix-directory /directory-not-allowed
Redirect 403 /directory-not-allowed
might be a gross, dirty hack, but it just might work for the moment.
I suppose the default-handler should be taught to recognize and fail
httpd/unix-directory requests with a 404. My only concern is that
this is -not- a 404, that level of the heirarchy -is- found, but
can't be processed in any meaningful way. Implies a 401 or 403.
The processing schema's changed enough that you tickled this oversight.
In fact, we are erroring out far more often (even in late 1.3.x builds)
due to the possibility of one module being tricked into failure, and
having another module pick up the request. E.g. some folks used
multiview matching on index documents, but those could (in some very
bizare and tangled circumstances) be evaded, and autoindex was picking
up the slack when the admin didn't intend for that to happen. We now
avoid Not Found as a 'catch all' if resources exist, otherwise such
potentials will always exist.
Thanks for the report, and let us know about the gross hack!
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org