On Fri, Mar 01, 2002 at 09:15:46PM -0800, Ryan Bloom wrote: > 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.
We're essentially creating a new request here. I'm not sure why you think we have to preseve the old protocol filters. They simply aren't valid anymore. They are for the old request - we want a *new* instance of these filters. The old request filters aren't valid for this type of sub-request - the contexts shouldn't be valid. The only filters with a valid context are the connection-filters. > > 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. How do you know which filters to add? There are number of places in the HTTP modules where they manually add CONTENT_LENGTH and HTTP_HEADER. My point is just to remove all of the duplicate code and allow modules to reset the filters. I can't believe that this will cause the server to be that much slower. By making it a hook, you abstract out the protocol - only the protocol engine knows which filters are required. -- justin
