Justin Erenkrantz wrote: >>Everything here (core_output_filter) revolves around apr_brigade_write >>and local variable n, which looks like the number of bytes that are >>about to go down the pipe: >> >>- to establish the total, we do: >> >> f->r->bytes_sent += n; >> >> after each write >> >>All other increments of r->bytes_sent have to be removed. I somehow >>don't believe it's that simple... Or is it? >> >> > >I believe it is. > >Now, there is *one* caveat on bytes_sent - keepalive connection may >not actually be written in the lifetime of that request (if the >response is small enough, we'll hold on to it until the next response >is ready and write both at the same time). > >That could end up with bytes_sent being 0 since we didn't write the >response immediately. On the next response, that bytes_sent value >would be the value of *both* responses. Ick, but I'm not entirely >clear how to get around that just yet. -- justin >
I think it's easy to solve the keepalive problem: core_output_filter() just needs to set r->bytes_sent as soon as it sees the EOS, rather than waiting until it writes the data. In the keepalive case, this means updating r->bytes_sent before the code that sets aside the brigade. 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? Brian
