Ryan Bloom wrote: > > We originally wrote the protocol filters to be connection based, but > that had some drawbacks that people were unwilling to live with, and it > made writing input filters very complex. Today, the filters that > implement the protocol are request based.
Gotcha. I checked back and re-discovered the problems. Durn shame, since they really are closer to being connection rather than request oriented, for non-stateless protocols. > of the request. > > The problem we have is that we have tied our protocol filters to the > lifetime of a resource, or a single request_rec in the server. I am > stating that I believe that the correct way to fix this is to split the > protocol and resource filters into two pointers. The resource-lifetime > filters are ignored on sub_request and internal redirects. The protocol > filters are by definition carried over from one request to the next, > until the request (from the user's perspective) is finished. > I think think would also tend to allow for better abstraction as well. But the ideal solution would be, to formally implement the protocol layer, even though not needed for HTTP/HTTPS. Of course, the overhead required may not be trivial. Then again, the filter division may allow us to "kinda" implement it anyway. -- =========================================================================== Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
