You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Gregory Ames <gr...@us.ibm.com> on 2002/04/04 00:02:43 UTC
subrequests & old_write in 2.0.32
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!