You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bojan Smojver <bo...@rexursive.com> on 2002/09/13 02:23:02 UTC
[PATCH]: mod_logio.c: Feedback sought
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...
Thanks,
Bojan
PS. The patch for mod_log_config.c and config.m4 is against 2.0.40, but
it does work for the current CVS head as well, with some offset.
Re: [PATCH]: mod_logio.c: Feedback sought
Posted by Bojan Smojver <bo...@rexursive.com>.
Actually, I told a lie there. If there is a header Content-Length in the
request, and there is a body, the mod_logio input filter will return
correct length of the body, without the headers. Looking at the example
of APACHECON_IN filter, I noticed a hook that puts the filter just after
the connection has been established, which then makes sure the headers
are filtered as well...
Soooo, back to coding ;-)
Bojan
On Fri, 2002-09-13 at 10:24, Justin Erenkrantz wrote:
> 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
>
Re: [PATCH]: mod_logio.c: Feedback sought
Posted by Bojan Smojver <bo...@rexursive.com>.
By searching the web for apr_brigade_length() I bumped into this page:
http://www.zend.com/lists/php-dev/200206/msg00467.html
apr_brigade_length() seems to be used there, most likely successfully.
Interesting...
Bojan
Quoting Justin Erenkrantz <je...@apache.org>:
> 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/
Re: [PATCH]: mod_logio.c: NEW FILTER?
Posted by Bojan Smojver <bo...@rexursive.com>.
After reading the document "Filtering I/O in Apache 2.0"
(http://webdoc.ucar.edu/apachecon2001/files/th5/filters/apcon.html), it
seems that only the connection based input filters have access to
headers. The request based input filters do not have access to headers
at all. That's why I was seeing zeros...
So, this seems to be the old chicken and egg problem - we need to know
what the request is, but we don't know that in the connection based
filter (i.e. f->r is NULL). Therefore, we cannot determine the length of
the headers in neither type of the filter if we want to be request
based. How do we fix this? It seems we have to introduce the middle
filter type that has access to headers but is request based.
Finally, one "tiny" detail - how do we do that?
Bojan
Re: [PATCH]: mod_logio.c: Feedback sought
Posted by Bojan Smojver <bo...@rexursive.com>.
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 <je...@apache.org>:
> 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/
Re: [PATCH]: mod_logio.c: Feedback sought
Posted by Justin Erenkrantz <je...@apache.org>.
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