> 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
We aren't creating a new request. The fact that we are simply copying the features of the request_rec to another request proves that this isn't a new request. > 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. That is BS. Those filters are completely valid. We are talking about moving them from the original request to the redirected request, just like we move other stuff. The protocol level filters are just as valid as the connection filters, the only real problem is that we don't have a structure that sits between the request and the connection. If we did, those filters would go there. > > > 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 Have you tried to write a module recently Justin? I am constantly trying to explain to people what each hook does. Adding another hook is a PITA for module authors, and I am against adding hooks that are absolutely not necessary. As for which filters to add, any filter that has an AP_HTTP_HEADER_TYPE type would be static for the request. The abstraction still exists, it is just that it is done with filter type instead of a hook. It still removes all of the duplicate code. It also makes the filter categories mean something other than just the order of the filter. The lifetime of the filter is the tied directly to the type of the filter. Ryan
