On Wed, 18 Sep 2002, Bojan Smojver wrote: > I understand. But isn't the ap_read_request HTTP specific given it's creating > the request and all? In other words, if protocol is HTTP, we let connection > filter know about the request. If not, we don't. That to me sounds exactly the > same as your suggestion. > > I must be missing something...
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. Ryan > > Bojan > > Quoting [EMAIL PROTECTED]: > > > You don't want to do this. A connection based filter is connection > > oriented. By definition, it has no concept of a request. While this > > might make sense for HTTP, other protocol modules will have a much harder > > time with this change. > > > > Ryan > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > -- _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
