Was this fixed in 2.0.32? ------------------------
This was a key reason for my mod_dir patch that broke Brian's request, below. This is also a mod_negotiation bug, we simply hadn't realized it yet. From: "Brian Akins" <[EMAIL PROTECTED]> Sent: Tuesday, February 12, 2002 7:35 AM > I've been playing with 2.0.31 and I've noticed something strange. All of our > .html and .htm files are server-parsed and should also have an expire time > set. ... > > A request for http://foo/ does not get parsed or get expiry headers set. > However, http://foo/index.hml works as expected. > > This just doesn't seem right, I have been toying with porting some of our > modules to Apache 2, but I obviously don't understand what's going here. Why > isn't http://foo/ recognized as text/html? No, it is not right, and yes - http://foo/ should be appropriately recognized. We are evidently not moving enough info from the subreq to the parent request in ap_fast_internal_redirect(); at least the filter chain, and some meta data related to the expires date.... Set{Input|Output}Filter[ByType] all set up filters in the typemap hook. It appears we did not copy these from the internal DefaultIndex subrequest back into the main request - we needed to. I'm not certain where the expires date is cached; the output headers? In any case, perhaps the entire headers need to slide from the sub request to the main request. A better answer is possibly to drop ap_internal_fast_redirect altogether (and changing both mod_dir and mod_negotiation to never use the beast again) - that includes Apache 1.3. This code, while normalized, is not much better than it was playing 1.3 negotiation. The code has been a source of vulnerabilities which I fixed, and other 'bugs' - most of which I'd fixed. Who knows how many more lurk, waiting to be 'discovered'. Axe ap_internal_fast_redirect()? Are any 3rd party modules taking advantage of this hack from negotiation? Bill -- Brian Akins Systems Engineer III CNN Internet Technologies
