On Wed, 18 Sep 2002, Bojan Smojver wrote: > Quoting [EMAIL PROTECTED]: > > > 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 _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
