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: > > http://www.apache.org:8092/dist/ > http://www.apache.org:8092/dist/httpd/ > http://jakarta.apache.org:8092/builds/
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: old_write byterange content_length http_header core 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: includes byterange content_length http_header core 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? Greg
