httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <>
Subject Re: [PATCH: Apache 2.0] mod_log_config: input/output bytes
Date Tue, 20 Aug 2002 11:54:43 GMT
On Tue, 2002-08-20 at 16:20, Justin Erenkrantz wrote:

> The problem here is that the length may not be specified via C-L,
> but rather Transfer-Encoding: chunked.  This system falls down
> in that case.  This is why I'd strongly recommend looking at
> trying to add r->bytes_read (or perhaps to a mod_log_config specific
> structure) to core_input_filter.

After reading a bit more from the function core_input_filter, here is
what I can conclude:

- to get to request from the filter, one would use f->r in that function
- since there is no r->bytes_read in current request_rec we could:
  - introduce one and break compatibility
  - store the bytes_read as in r->notes, which is easy but not right
- the actual number of bytes read is stored in local variable len:
  - the r->bytes_read would just be:

    f->r->bytes_read += len;

    after each read

> If you read some of Brian Pane and rbb's recent posts, r->bytes_sent
> needs to move to core_output_filter, so I think something similar
> for input accounting is the way to go here.  It's ridiculously easy
> to compute the real length in core_input_filter as it knows how much
> it just read (or just do an apr_brigade_length call on b before
> returning it).

So, r->bytes_sent would then be completely different that in the current
version of Apache 1.3/2.0, which simply reflects the length of the body?
Would others be inclined to accept such a change?

Everything here (core_output_filter) revolves around apr_brigade_write
and local variable n, which looks like the number of bytes that are
about to go down the pipe:

- to establish the total, we do:

  f->r->bytes_sent += n;

  after each write

All other increments of r->bytes_sent have to be removed. I somehow
don't believe it's that simple... Or is it?


View raw message