Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: 
 <DCD82CE6D2ADD311A98E0008C7A4C929080E36E0@cnfqs039.cnf.prod.cnf.com>
From: "Bennett, Tony - CNF" <Bennett.Tony@cnf.com>
To: "'dev@httpd.apache.org'" <dev@httpd.apache.org>
Subject: RE: apache 2.0.43: %b not showing "bytes sent" but "bytes  reques
	ted"
Date: Fri, 11 Oct 2002 08:29:31 -0700
MIME-Version: 1.0
Content-Type: text/plain

I believe the %b gets its value from the request_rec's bytes_sent
member.  This field is filled in by the content_length output
filter.  It is not filled in during the actual send operation.
Even if it was filled in following each "send", that doesn't 
mean it was received by the client... in the event of a disconnect,
I believe the bytes_sent will always be off.

-tony

-----Original Message-----
From: David Burry [mailto:dburry@tagnet.org] 
Sent: Friday, October 11, 2002 1:59 AM
To: dev@httpd.apache.org
Subject: Re: apache 2.0.43: %b not showing "bytes sent" but "bytes
requested"


ok.... serious problems still...  I've sucessfully installed mod_logio
(finally), and %O is STILL not logging the actual bytes transferred, but the
bytes apache is INTENDING to eventually transfer... if I stop it in the
middle by canceling or disconnecting, this number is horribly too big!!!!
Of course it's a couple bytes larger than %b because of the headers
included, but this is still totally useless for the purpose of figuring out
if/when/whether the whole file was actually downloaded.  Anyone have any
ideas why this is so and how to fix it?  Is the logging happening completely
before the request is finished, could that be the problem?

This should also be a concern for anyone who's using mod_logio to charge for
bandwidth, because customers should be concerned about some serious
overcharging going on here!

I had to install libtool 1.4 and m4 1.4 and this was my configure line:
./configure --prefix=/usr/local/apache_2.0.43+logio --enable-logio --enable-
usertrack --enable-file-cache --enable-cache --enable-mem-cache --enable-sta
tic-support --disable-cgid --disable-cgi --enable-rewrite --with-mpm=worker 
--disable-userdir


Dave

----- Original Message -----
From: "David Burry" <dburry@tagnet.org>
> Yes, I've been thinking of experimenting with mod_logio, but I'm a bit
> hesitant to hack out a patch from (or use whole-hog) CVS HEAD into a
> production site that gets 3 terabytes of traffic per day and I'm
embarassed
> to admit how much revenue depends on... ;o)  Thanks for the link, I'll try
> that.  It won't be as accurate as getting the byte count without the
> headers, but at least it should be something better than nothing if it
works
> as described...
>
> If we're not going to fix %s shouldn't we at least fix the documentation
to
> be more accurate?  2.0 and 1.3 really are quite different here.
>
> Dave
>
> ----- Original Message -----
> From: "Bojan Smojver" <bojan@rexursive.com>
> > Have you tried using mod_logio? If won't only give you the "body" bytes,
> but
> > also the "headers" bytes. It reports the number of input bytes too and
> should
> > understand encryption and compression. You can either check it out from
> Apache
> > CVS (HEAD), or download the patch for 2.0.43 here:
> > http://www.rexursive.com/software.html.
> >
> > You'd use it with %I (for input) and %O (for output). It would be
> interesting to
> > know if it reports accurately in the case you described...
>