I believe the attached .patch file should resolve our issues with the subrequest negotiation. Essentially, we want the sub request to build a new filter chain if we plan on using the subrequest as a 'fast internal redirect'.
This patch does just that, when we fast redirect, we replace the original request filters with the new request filters. In preparing the request, we go back to our favorite r->connection filters to start, when we are making the subrequest with a NULL next_filter. But the patch is broken. Free beer at ApacheCon 2002 to the first hacker who untangles the misbehavior that fouls up this patch. Make that hard stuff if you discover it's a simple bug in my patch :) One hint. I think our whole "Either Connection or Request" idea of filters is borked. It really seems that "Either Connection or Protocol or Body" is a much better model - this bug seems to prove that once again. I think we really wanted to grab r->http_input_filters and r->protocol_output_filters when we set up the subreq of next_filter==NULL. But there doesn't appear to be such a thing. Bill
subrequest.patch
Description: Binary data
