Le 05/04/2018 à 14:18, Jonathan Valliere a écrit : > I am concerned that it is bad precedent to add handler methods based on > specific filters. The purpose of the filter system is that each filter has > no direct knowledge of what is before or after it. Maybe there could be a > generic “event” handler as part of the receive chain that the SECURED event > could flow down instead?
Years agao, we had a discussion about the place where the SSL/TLS handling should be done. I strongly believe that it does not belong to a filter (this is a source of confusion, because it always has to be the very first filter in the chain), but to the HeadFilter (or something like that). In other words, establishing a secured session is intimely coupled with any IO operation, regardless of the application built on top of it. Any other filter is functional, and related to the protocol being set, but TLS/SSL is different, IMHO. Now, your idea to have a otherEvent() method - or whatever could be the name - that covers any event we would like to generate in any filter sounds like a good idea too. We can explore this route. And, to be frank, this is the reason I asked on the mailing list : having the opportunity to ear about other proposals that could make more sense ! Thanks ! -- Emmanuel Lecharny Symas.com directory.apache.org
