The documentation for Apache 2.0.43 for mod_log_config states: %...b: Bytes sent, excluding HTTP headers. In CLF format i.e. a '-' rather than a 0 when no bytes are sent.
However, in testing I clearly see it's logging the number of bytes _requested_ (that is, that apache intended to send)!!! not the actual bytes _sent_!!! If a user presses the cancel button on their browser or they're cut off in the middle, this number is not accurate at all, because it appears the entire file was sent when it was not. We're running a site that serves many large files (dozen megs or so typically) for download. It depends on this "bytes sent" number for statistics and monitoring to see if and when a download has completed including with a "206" byte range response... Typical throughput is 600 mbit/sec, 3 terabytes/day, running on Solaris 8 on 4 Sun E280R's with 4 gig of ram each... We're seriously considering rolling back to old hardware with Apache 1.3.x (which seems to log actual bytes sent by the way) and CacheFlow machines because of this issue... Is there a patch out for this problem instead? or is someone already working on this problem? or does anyone have an idea where the root of this problem is and I might take a stab at patching myself? As a side note, we tried but we were unable to use mod_mem_cache on this setup we suspect due to mutex issues, might be possible if we spread this out over more machines (but what's the point of memory caching if you have to do that), mod_file_cache works ok though for a static list of the most-often-used files, though mmap does have its limitations on how large of a file can be stuck into memory... We have sendfile installed and I configured with the following: ./configure --prefix=/usr/local/apache_2.0.43 --enable-usertrack --enable-file-cache --enable-cache --enable-mem-cache --enable-static-support --disable-cgid --disable-cgi --enable-rewrite --with-mpm=worker --disable-userdir Dave
