[EMAIL PROTECTED] wrote:
>The cleanest solution, is to move the bytes_sent to the conn_rec, but then
>it should really be per-connection, not per-request, and we want it to be
>per-request.
>
>The other solution is to have the core figure out the correct amount of
>data in the core_output_filter, and then fill out the request_rec in a
>later hook, but that is also kind of bogus.
>
>Adding the request_rec to the bucket is a bad idea, because currently
>buckets have no concept of Apache internals, and I would prefer that they
>stay that way.
>
The trick is to not add the request_rec to the bucket: just add a
void* "client_data" field to the bucket, so that apr-util doesn't
have to know anything about the httpd.
However, we can avoid this altogether if the the alternative
described below works:
>Adding the request_rec to the CONNECTION filters is also a bad idea,
>because those filters really shouldn't _need_ anything from the request,
>and connections don't always have requests, especially not in all
>protocols.
>
>IMO, the best solution is to move the bytes_sent information to the
>conn_rec, and have the protocol module reset it whenever it wants to. For
>backwards compat, it would be REALLY cool, if the r->bytes_sent could be
>linked to c->bytes_sent, but it can't, so oh well.
>
If we add c->bytes_sent but keep r->bytes_sent, I *think* we can
compute both. The logic would look like:
* In core_output_filter, update c->bytes_sent. But count the
bytes when we scan each bucket, rather than waiting until
we actually send it. (I.e., for keepalive responses, we need
to update c->bytes_sent *before* we setaside any buckets.)
* When creating a new request, make a note of its c->bytes_sent
value. At the end of that request's processing (as a "really_first"
logger callback added to the core, I suppose), compute
r->bytes_sent as the delta in c->bytes_sent since the start of
the request. Then any loggers that depend on r->bytes_sent can
continue to use it.
Brian
