mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Valliere <jon.valli...@emoten.com>
Subject Re: Adding a secured() event in the IoHandler
Date Thu, 05 Apr 2018 13:42:35 GMT
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 <elecharny@gmail.com>

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message