On Tue, Aug 20, 2002 at 09:54:43PM +1000, Bojan Smojver wrote: > 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
All that would require is a MMN bump. (We're just adding a field, so that's what a MMN bump is for.) > - 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 Indeed. > 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? Totally. The current behavior is broken. We all pretty much agree that it is wrong. > 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? I believe it is. Now, there is *one* caveat on bytes_sent - keepalive connection may not actually be written in the lifetime of that request (if the response is small enough, we'll hold on to it until the next response is ready and write both at the same time). That could end up with bytes_sent being 0 since we didn't write the response immediately. On the next response, that bytes_sent value would be the value of *both* responses. Ick, but I'm not entirely clear how to get around that just yet. -- justin
