On Tue, 2002-09-17 at 21:46, 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.
The real problem is that "r" is HTTP-specific. If we were designing the server from scratch, I suppose we could introduce a protocol independent "generic request structure" for use in any protocol that had some sort of discrete request, and make that accessible within the connection-level filters. But for historical reasons, the request_rec is HTTP-specific. However, if you can do the byte counting in a request-level filter (right after the HTTP output filter?), that should enable you to bypass the problem. Brian
