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
