I'll try this on my test machine today. Ryan
---------------------------------------------- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:trawick@rdu88-250- > 035.nc.rr.com] On Behalf Of Jeff Trawick > Sent: Friday, April 05, 2002 7:56 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [PATCH] Fix mod_autoindex > > (This is a reply from [EMAIL PROTECTED] His normal e-mail access > is fsck-ed at the moment. I'm just the messenger.) > > "Ryan Bloom" <[EMAIL PROTECTED]> writes: > > > This is another attempt at fixing mod_autoindex. This works for me on > > my computer, and it explains the problem. I haven't been able to > > actually reproduce the problem, but I have seen the symptoms. Can > > somebody who can reproduce PLEASE test this on their setup. I am hoping > > to setup a failure condition soon so that I can test this myself. > > the following from apache.org's config file might help: > > <IfModule mod_autoindex.c> > > # If MultiViews are amongst the Options in effect, the server will > # first look for name.html and include it if found. If name.html > # doesn't exist, the server will then look for name.txt and > # include > # it as plaintext if found. > # > ReadmeName README > HeaderName HEADER > > </IfModule> > > If you want to get rid of the dependency on > MultiViews/mod_negotiation, > > ReadmeName README.html > ReadmeName HEADER.html > > ..would probably work. > > > I may commit this either way, because even if this doesn't fix the > > problem from apache.org, it does solve a problem with data ordering. > > > > This is the cleanest way I could find to solve the problem, but I am > > perfectly willing to listen to other ideas. > > I see three problems with mod_autoindex in 2.0.34 when it has to serve > both a HEADER and README file (highest priority first): > > 1. the subrequest filter has to be present for normal subrequests that > generate output, > > 2. if the main request does ap_rputs, then creates & runs a > subrequest, the subrequest filter and any resource filters need to > be inserted on top of the main request's OLD_WRITE instance so the > older ap_rputs data gets flushed, and > > 3. (the problem that Ryan's patch is attempting to fix) if a module > creates a subrequest, then does ap_r* for the first time, then runs > the subrequest, you get out of order data. This problem pre-dates > 2.0.34. > > You can see problem #3 on the production server at > http://www.apache.org/dist/httpd/ . The page displays OK, but if you > view the html source, notice that the <h1> thru the 2.0.32 beta > announcement (from the HEADER.html file) is in front of <!DOCTYPE thru > <body> (the first content that mod_autoindex generated via ap_rputs). > > I think the first thing we need is something like Jeff's patch for > inserting the subrequest filter, reworked to accomodate the "promoted" > subrequests like DirectoryIndex. > > #2 is what produces the visible out-of-order data at the bottom of the > autoindex display in 2.0.34. I suspect this happens because we now call > OLD_WRITE a resource filter, but that's just a guess. I'll volunteer > to analyze this more closely. > > Then we need something for #3. IMO it is low priority because it has > existed for ages, and isn't visible AFAIK. Clearly we should address > it before GA. > > Greg > > p.s. I've been without Apache e-mail for a couple of days due to a > server upgrade. I posted a detailed analysis of #3 from an alternate > e-mail address, but still don't see it.
