Sorry I wasn't around to add my 2 bits to this discussion, but I'm
kinda OK with this solution. Only question is - what will happen if
data is received in the middle of this process? Will it be given to
the SSLFilter or not?
I'm also of the opinion that a "filter bypass" solution should be
abstracted as a one-time solution to such race conditions.
What I'm doing right now as a workaround to this problem is
implementing my own filter which simply keeps buffering all the
incoming data till the sslfilter is implemented. After that, I remove
the filter and retrieve all the data.
Regards,
Vinod.
On 10/13/05, Trustin Lee <[EMAIL PROTECTED]> wrote:
> 2005/10/13, Julien Vermillard <[EMAIL PROTECTED]>:
> > Why not :
> >
> > public void messageReceived(IoSession session, Object message) {
> > if (message instanceof MyStartTLSRequest) {
> > // insert SSLFilter to start handshaking
> > session.getFilterChain().addFirst(sslFilter);
> >
> > // Disable encryption
> > sslFilter.setEnabled(false); // SSLfilter is bypassing
> >
> > // write StartTLSResponse
> > session.write(new MyStartTLSResponse(OK));
> >
> > // Enable encryption
> > sslFilter.setEnabled(true); // SSLfilter is crypting
> > }
> > }
>
> What if a client initiates TLS handshake process before we call
> sslFilter.setEnable(true). I know this won't happen easily, but it has
> possibility of race condition yet.
>
> I talked with Emmanuel and here's another option:
>
> public void messageReceived(IoSession session, Object message) {
> if (message instanceof MyStartTLSRequest) {
> // insert SSLFilter to start handshaking
> session.getFilterChain().addFirst(sslFilter);
>
> // Disable encryption temporarilly. This attribute will be cleared
> after Session.write()
> session.setAttribute( SSLFilter.DISABLE_ENCRYPTION , Boolean.TRUE );
>
> // write StartTLSResponse
> session.write(new MyStartTLSResponse(OK));
> }
> }
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
