At 02:51 AM 7/14/2002, you wrote: >Currently, the content-length filter attempts to compute the length >of the entire response before passing any data on to the next filter, >and it sets request_rec->bytes_sent to the computed content-length. > > * r->bytes_sent is used by mod_log_config as a count of bytes sent > to the client (minus response header). But the value that's > computed in the C-L filter isn't necessarily equal to the number > of bytes sent, as there may be additional filters between the > C-L filter and the client that affect the output (the chunking > filter, for example, or mod_deflate).
AFAICT, We do _not_ care about bytes manipulated after body content processing for r->bytes_sent. If you want to create a new r->bytes_transmitted field tracking the actually bytes sent over the wire, that's fine. When folks check their logs, they expect to see the number of bytes of content in that count, which provides some level of confirmation that the response was handled properly (if my index.html file is 1474 bytes, I'm looking that all 1474 bytes are sent.) r->bytes_transmitted would be very interesting to me [looking at SSL connection traffic, for example.] But it shouldn't replace r->bytes_sent.
