httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: 2.0.34 - erratic behavior with autoindexes
Date Tue, 02 Apr 2002 21:50:59 GMT
> 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
> (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
> 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
> 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
> the
> data generated by the main request when the trailer file is sent down
> 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.

If you read through mod_include, you will see that whenever we create a
sub-request, we send the output from the current filter to the next
filter.  This is required to make sure that things are output in the
correct order.  If you are a handler and are generating data through
ap_r* functions, you must flush the filter stack so that you are sure
that OLD_WRITE isn't buffering for you.

This will solve SOME of the problem.

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

The http_header filter is never called for the sub-request, because it
is only added for the main request.

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

This is the thing that is most worrying.  Without that filter,
everything is going to hell in a hand-basket quickly.


View raw message