From c38089c77cb8fed0270f0e7309f314175752c07d Mon Sep 17 00:00:00 2001 From: Bill Stoddard Date: Fri, 22 Mar 2002 16:15:43 +0000 Subject: [PATCH] Not a showstopper IMO. But posting a patch anyway... git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94130 13f79535-47bb-0310-9956-ffa450edef68 --- STATUS | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/STATUS b/STATUS index 7af19f1af0..800761bd3b 100644 --- a/STATUS +++ b/STATUS @@ -1,5 +1,5 @@ APACHE 2.0 STATUS: -*-text-*- -Last modified at [$Date: 2002/03/22 15:22:24 $] +Last modified at [$Date: 2002/03/22 16:15:43 $] Release: @@ -68,11 +68,18 @@ FINAL RELEASE SHOWSTOPPERS: simple check in default_handler to see if dir/file_walk has been done (a footprint left by dir/file_walk doesn't have to be in request_rec; a better place is core_request_config) - + + BillS: I think the common case will be caught in + default_handler already (with the r->finfo.filetype == 0 + check). A module would have to explicitly init r->finfo.filetype + then its handler would have to decline the request. Seems + to be an unlikely combination as most (all?) modules bypassing + directory_walk are not serving content out of the file system. + gregames says: can this happen somehow without a broken module being involved? If not, why waste cycles trying to defend against potential broken modules? It seems futile. Please vote. - not a showstopper: gregames + not a showstopper: gregames, BillS showstopper: * API changes planned for 2.0 that should happen before the -- 2.40.0