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?
Bojan
