httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: 2.0.34 - erratic behavior with autoindexes
Date Tue, 02 Apr 2002 21:29:50 GMT
Greg Ames wrote:
> I noticed something weird on daedalus on the test build.  It looks like we're
> not autoindexing directories with HEADER.html or README.html files correctly.
> You see the contents of HEADER.html and/or README.html, but not the other files
> or subdirs in the directory.  Often, the Mozilla animation keeps going as if the
> browser thinks more info is coming.
> Examples of the failure:

OK, the same bad behavior happens on my ThinkPad with HEAD, so I've been
slogging thru it with gdb.  I suspect the cause is the change the re-classified
the filters and changed when they are added etc.

In handle_autoindex, we are working on the main request upon entry. 
r->output_filters looks like:


When it sees that HEADER.html exists, it apparently fires off a subrequest
(can't say for sure, I hit "n" in gdb rather than "s" at the wrong time :-(  ). 
That finishes, and index_directory starts reading the directory entries and
creating the html fragments for them.  This all seems fine.  It writes them with
ap_rputs, which should buffer the little pieces of data in old_write.

Once it gets done with the normal files and subdirs, it finds README.html, and
definitely calls 
ap_run_sub_rec for that (I hit "s" this time :-).  When we get to
default_handler, r->output_filters looks like:


The includes filter is using the subrequest's r; byterange, c/l, and http_header
are using the main request's r; core has a null r.

If you've been following this list for a while, you probably know that things
are going to get funky real quick.  AFAIK old_write is still buffering all the
data generated by the main request when the trailer file is sent down the filter
chain.  Bill S. stuck his head in here and said something about a rule that if
old_write is ever used, it has to always be used.

Other things that may or may not have a bearing:

 * the includes filter parses the HEADER and README files, so the subrequest
FILE buckets get morphed into MMAP buckets.

 * stepping thru the http_header filter on the README/trailer subrequest was
interesting.  It sure looks like that bad boy is generating headers during the
subrequest.  It has a debug assert(!r->main).  It doesn't hit because the r came
from the filter structure, and it's the main request's r.  It does take itself
out of the filter chain after it is done with the trailer subrequest.  

 * what happened to the subrequest filter?  what is going to stop subrequest EOS
buckets from really flushing data to the network prematurely?


View raw message