The issue isn't mod_autoindex at all. Mod_dir is now implemented in terms of a fast_internal_redirect.
This makes sense, when you consider that a subreq for /foo/ should return type "text/html" if that will be the results of a real request for /foo/. But in this -one- case, I see the issue/confusion. I would be very adverse to changing mod_dir back to returning whatever goofy "application/x-unix-dir" we had in 1.3, but we could agree to skip the subreq on a dir, if we can agree that requests for /foo/ that will error out or are protected are then displayed always. I doubt most admins want /foo/ listed if it is a protected resource, so the default needs to remain as-is with a full subreq lookup test. > > > Upon closer inspection... the code is looking for index.html and > > > index.html.var in each > > > subdirectory. Havent tested to see how far down the code will > > recurse.. > > > This is just > > > goofy. > > > > That is goofy, but the reason it is happening, is because we redirect to > > the index.html page from the fixups hook. I can't remember if this used > > to happen in 1.3 or not. > > > >I can understand the redirect, but why the directory recursion? Let me >look at what else using the dirent call... >-- >=========================================================================== > Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ > "A society that will trade a little liberty for a little order > will lose both and deserve neither" - T.Jefferson
