On the theory that the recent problems with autoindex output are strictly due to filter ordering issues, I decided to walk thru 2.0.32 with both a HEADER and a README to see how that worked. The second subrequest, for the README/trailer, is pretty straight forward. mod_autoindex has already done a bunch of ap_rputs, so OLD_WRITE has data stashed in its brigade. When the subrequest makes it to the default_handler, here's how things look:
The main r->output_filters: OLD_WRITE -> C-L ->HTTP_Header -> core (byterange has removed itself) subreq rr->output_filters: INCLUDES -> SUBREQ_CORE -> OLD_WRITE -> C-L -> HTTP_Header -> core That all works very nicely. OLD_WRITE concats the new brigade with the MMAP bucket behind its buffered data, and sends the result down the chain. But the first subrequest, for HEADER.html is a little funky. This normally isn't visible unless you look closely at the HTML. You can see it on our production server at http://www.apache.org/dist/httpd/. Once there, do "View...Page Source" (Mozilla or Netscape) or "View...Source" (IE5). Notice that the <h1> down thru our beta announcement come before the <!DOCTYPE> thru the <body>. That's backwards, but the browsers don't seem to care. mod_autoindex::emit_head calls ap_sub_req_lookup_uri to see if a HEADER file exists. It does. This also creates the subrequest rr. But at this point in time, the OLD_WRITE filter isn't anywhere because no ap_r* operations have been done. Then it calls emit_preamble to write the <!DOCTYPE > etc using ap_rputs. So OLD_WRITE gets added to the main r->output_filters, but not the subrequest rr. Next, emit_head calls ap_run_sub_req(rr) to actually send the file data. This is where things get out of order. When we get into default_handler, we have: main r->output_filters: OLD_WRITE -> byterange -> C-L -> HTTP_Header -> core subreq rr->output_filters: INCLUDES -> SUBREQ_CORE -> byterange -> C-L -> HTTP_Header -> core When the first subrequest ends, the contents of the HEADER file get sent down to the C-L filter, but OLD_WRITE is still hanging on to the preamble data, totally unaware of the first subrequest. Once the second subrequest comes along, all of OLD_WRITE's buffered data gets flushed as described above. IMO this is lower priority than the 2.0.34 problems, but should be fixed before we GA. There could be clients that are less tolerant of out of order data than browsers. It's kind of a corner case, but I can envision other modules doing something similar, and would rather not debug it on a user's production system. Greg p.s. could you please cc this e-mail address if you reply? My usual e-mail server is getting upgraded. Thanks!
