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. 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... Bojan ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
