httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: [PATCH]: mod_logio.c
Date Tue, 17 Sep 2002 06:20:06 GMT
On Mon, Sep 16, 2002 at 11:44:36PM +1000, Bojan Smojver wrote:
> This patch is against the current CVS and it enables logging the number
> of input/output bytes per request, which is then useful for producing
> actual statistics per virtual host or whatever else.
> 
> I have tested the module lightly and it works for me. The trick was to
> employ both connection and request based filters and link them together.
> I did that through connection notes. I'm not sure if this is the correct
> way of doing things, but it does seem to produce accurate numbers in my
> tests. I would really appreciate if someone could take a look and verify
> if this is something that can be worked with.

Is there a reason that everything can't be done on the conn_rec?
What's the reason for having the request-based input filter again?
(Please refresh my old and decrepit memory!)  Can't we do everything
in the connection filter?  Isn't this just going to duplicate
everything (i.e. the conn filter sees it once, then the request
filter sees it again)?

In fact, if we make it a request filter, aren't connection-level
filters such as SSL make the value different?  For a SSL connection,
we have to set these values *before* (on input) or *after* (on
output) SSL gets it.  We're only concerned with the actual bytes
transmitted on the network socket.

I still think we can work it out so that the connection filters
have a pointer to the request_rec.  (i.e. ap_read_request could
update a pointer within the conn to indicate the current request
*or* update all of the current input filters to point at the new
request_rec.)  I think we can manage something that won't get
vetoed.

And, again, I'm totally in favor of having this filter update/modify
r->bytes_sent/r->read_length (perhaps replacing read_length in favor
of bytes_read to be consistent).  I maintain the definition of
bytes_sent excluding the headers is remarkably lame and no one ever
really wants that anyway.

Has anyone said it should remain broken?  If so, why?  -- justin

Mime
View raw message