httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <>
Subject Re: [PATCH]: Update request in connection based filters
Date Wed, 18 Sep 2002 04:46:15 GMT

> The problem is that the filters aren't HTTP specific.  If you make this
> change, then the filters will be written to take advantage of the f->r
> field in connection level filters.  Since that field doesn't make sense in
> non-HTTP requests, modifying the filter_rec so that it is there is a
> mistake.
> Think about it this way.  If you add the request_rec to the
> core_output_filter, and that filter is modified to use it, then all
> protocol modules must ensure that the request_rec is added to the filter,
> even if it doesn't make sense.
> If you make it optional to put the request_rec in the filter_rec, then you
> will be making it much harder to write filters.

OK, I think I understand now what you're trying to say. Things can go wrong if
important fields can be NULL when you want them to be non-NULL and vice versa. I
reckon that good documentation on the matter would help developers understand
that they cannot depend on f->r being set for some protocols, which would
eliminate confusion. But, this is the first ever filter that I'm writing and
it's awfully simple, so I could be dead wrong.

Let me go back to the core of the problem - how do I store the number of bytes
that were sent/received on the wire into the request_rec structure in order to
log that? After discussion with Justin, it seemed that connection based filters
were the place to do it because request based filters either don't see the input
headers or they don't take into account things like SSL. I mean, logging
something like that should be a fairly trivial exercise and yet it seems to be
creating major dramas...


This mail sent through IMP:

View raw message