httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH]: Update request in connection based filters
Date Wed, 18 Sep 2002 14:05:55 GMT
On Wed, 18 Sep 2002, Bojan Smojver wrote:

> Quoting
> > 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.

It isn't that you are "dead wrong", but that type of situation where a
field can be uninitialized based on protocol is going to be almost
impossible to debug.  The point of filters is that they are stand-alone
functions, if you give them the information they expect, they will
work.  If you add the r field to connection filters, somebody will look at
it and write a connection filter that requires it to be there.  Once that
happens, the filter will only work with HTTP.

> 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...

The easiest way, would be to put the filters in mod_log_config, and have
that module save the information in a connection_rec vector.


Ryan Bloom               
550 Jean St
Oakland CA 94610

View raw message