> 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.
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 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. 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. Ryan
