Yes, its different in that it may act like a buffer, in some phases, but doesn’t necessarily break the pattern of filter use. What your FilterChain needs is fire(index) options so the SSL can fire writes relative to itself, in response to a read, without having to choke down the whole chain with special exceptions via flags in setAttributes. Make a lot of the design easier. IMHO, I think the biggest problem is the design of SSL filter and the limitations of the Filter API.
On Thu, Apr 5, 2018 at 9:22 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > > > 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 > >
