> On Fri, Mar 01, 2002 at 04:50:16PM -0800, Ryan Bloom wrote: > > I don't understand how this is working. The original code from Will > > came from a discussion that he and I had over the phone. My question is > > how were the protocol specific filters removed in this case? > > > > Oh, damn, the problem is that these filters are request specific instead > > of connection specific. What we really need, is a filter type that is > > request specific, but that isn't specifically tied to the request. > > Basically another field in the request_rec, which would store all store > > all HTTP_HEADER filters. That way, they wouldn't be lost for > > sub-requests and internal redirects. > > Yes, but the concept of the protocol is intertwined with the concept > of a request. A request should be one "transaction" of a protocol > interaction. A protocol filter shouldn't survive successive > iterations of a "request" - we saw that didn't work for HTTP.
You are thinking of this wrong. Filters that are stored on r->protocol_filters wouldn't survive a single request, they would be required for the lifetime of the request. The idea is that anything that lives in r->output_filters would be allowed to be removed by the server code at will. Anything on r->protocol_filters would be static for the lifetime of a request, and c->output_filters survives a request. > What's wrong with a simple hook that lets the protocol engines add > filters to a request? -- justin Because the more hooks we add, the more complex it is to write a module, and the slower the server actually goes. Also, why should this be a hook? There are a set of filters that absolutely must survive for the lifetime of a request and no longer. Those are protocol filters, and they shouldn't be treated equivalently to content filters. Ryan
