Bojan Smojver wrote: >On Thu, 2002-08-22 at 09:03, [EMAIL PROTECTED] wrote: > > >>>>IMO, the best solution is to move the bytes_sent information to the >>>>conn_rec, and have the protocol module reset it whenever it wants to. For >>>>backwards compat, it would be REALLY cool, if the r->bytes_sent could be >>>>linked to c->bytes_sent, but it can't, so oh well. >>>> >>>> >>>Why don't we just add up the lengths of headers and the status line and >>>be done with it? It will be accurate, since we know which headers are >>>being sent out. >>> >>> >>It's the body data that I care about, and you don't know that it will be >>accurate, because the client could have terminated the request half-way >>through sending the headers. >> >> > >OK. I get it now. I hope you guys are not annoyed by my lack of >knowledge... Sorry, I just started playing with the source a few weeks >back. > >So, bytes_sent will continue to be the amount of body sent out only, no >headers? If that's the case, then the only option (if we want to know >total counts) is to introduce bytes_pushed and bytes_pulled (or similar) >into request_rec. Does that sound feasible to you? > >
That sounds reasonable, although we might end up with some data from which it's possible to compute bytes_pushed, rather than an actual bytes_pushed field. With the c->bytes_sent idea that Ryan and I were just discussing, we'd probably have to keep track of something like r->header_bytes_sent in order to properly compute the content bytes sent for the logger. So you might end up having to get add r->header_bytes_sent plus r->bytes_sent to get the total. But one way or another, I think it's feasible to get the data there. :-) Brian
