Ryan Bloom wrote: >>From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] >> >>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. > >In 1.3, r->bytes_sent was the number of bytes actually sent to the >client. That is what it should continue to be in 2.0. >
+1 --Brian
