I have tried that, but with no luck... Time to escalate to the second guess :-)
And just on the topic of filter types, if I do AP_FTYPE_CONTENT_SET or AP_FTYPE_RESOURCE, then the length is 0, even for HTTP/1.0. I know those wouldn't be good because they don't take into account the headers, but I tried anyway. AP_FTYPE_PROTOCOL behaves similar to AP_FTYPE_TRANSCODE - zero for HTTP/1.1 and nothing (i.e. not set) for HTTP/1.0. AP_FTYPE_CONNECTION and AP_FTYPE_NETWORK behave similar to AP_FTYPE_TRANSCODE. My 'feeling' is that AP_FTYPE_TRANSCODE (or something around that) should be the correct one - it is tied to the request and yet has all the transports stuff already 'attached' to it, which should then result in the correct size (at least for the output it does). Bojan PS. I have noticed, by looking at mod_deflate.c, that some of my main/sub-request logic is not entirely up to scratch, so I have rewriten the code somewhat. Once the actual counting starts working, I'll submit that instead. Quoting Justin Erenkrantz <[EMAIL PROTECTED]>: > On Fri, Sep 13, 2002 at 10:23:02AM +1000, Bojan Smojver wrote: > > This is what I came up so far, but I've hit a problem along the way. No > > matter what I do (or should I say, whatever I tried to do so far :-), > > the number of input bytes is zero (HTTP/1.1) or not even calculated > > (HTTP/1.0). The number of output bytes is correct, at least in my tests. > > Could anyone point out what kind of silliness am I doing in the input > > filter? I kind of understand what output filters do, but I'm still a bit > > vague on input filters... > > I think the second parameter to apr_brigade_length in the input > filter may need to be 1. > > The thing is that you may be getting the socket bucket which has > an indeterminate length. Therefore, you need to force a read_all > to occur. I'm not exactly sure if that's what is happening, but > that's my first guess. -- justin ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
