(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.
