On Wed, 21 Aug 2002, Justin Erenkrantz wrote: > On Wed, Aug 21, 2002 at 12:27:29AM -0700, Brian Pane wrote: > > The remaining problem is: how can we identify the request_rec from > > within core_output_filter()? Within that filter, f->r is NULL. I > > have some ideas for solving this by putting some metadata in the > > brigade to associate each EOS with the corresponding request. > > But is there a better solution that already exists for getting > > the request_rec? > > Actually, I thought it was already fixed, but you're right the > connection filters don't yet have access to f->r. > > My thought would be when we create the request, we go through the > filter stack and 'fixup' all filters in the output_filters chain > to point at the right request_rec. Seems easy enough, but I'm not > 100% sure that is clean enough. -- justin
You don't really want to do that. The problem is that a connection can have multiple requests, which means that if you have a CONNECTION_FILTER with access to the request_rec, at some point, it will have invalid information about the current request (i.e. in between requests). The CONNECTION filters specifically do not have access to the request_rec, because they shouldn't be doing anything with the requests. To solve the original problem, just look for ap_check_pipeline_flush, and around that function (or in the core's log_transaction phase), just reset c->bytes_sent to 0. If you do it in the core's log_transaction phase, just make sure that the function is registered AP_HOOK_REALLY_LAST. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
