directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [mina] SSLFilter race condition: Take #2
Date Thu, 13 Oct 2005 14:57:28 GMT
2005/10/13, Rodrigo Kumpera <>:
> I think this kind of problem will be present in many more situations
> than just SSL. The situation, if I understand correctly, it's a state
> transition in the way the stream must be processed.

I agree, but there are no known filters which are related with this issue,
so it might be too early to think about it. It would be great if you can
give use some example use case you can imagine. They will be mostly content
transformation filters which requires StartTLS-like negotiation.

I think mina ether need a filter passthrou schema (eg, 'tls-ok'
> ignores the ssl-filter) or a way to have proper ordering of events so
> the ssl-filter will onyl apply to packets after 'tls-ok' and
> 'start-tls'.

Could you explain a bit more about passthrough schema?

About packet ordering, what about a way to say that a filter have a
> boundary of when to start working:
> public void messageReceived(IoSession session, Object message) {
> if (message instanceof MyStartTLSRequest) {
> Object reply = new MyStartTLSResponse(OK);
> // insert SSLFilter to start handshaking, it will work on all
> packet after message and reply.
> session.getFilterChain().addFirst(sslFilter, message, reply);
> // Disable encryption temporarilly. This attribute will be
> cleared after Session.write()
> session.setAttribute( SSLFilter.DISABLE_ENCRYPTION , Boolean.TRUE );
> // write StartTLSResponse
> session.write(reply);
> }
> }

This code is a little bit strange. Why should I pass 'message' to
addFirst()? And we still have session.setAttribute(...). Could you explain
about this in detail?

what we call human nature is actually human habit

View raw message