On Tue, 2007-01-16 at 14:10 +0100, Oleg Kalnichevski wrote: > On Tue, 2007-01-16 at 10:26 +0530, Asankha C. Perera wrote: > > Hi Oleg > > > > > We are currently working on improving the blocking version of HTTP > > > connection management components in HttpConn module of HttpClient, but > > > certain adjustments in priorities in order to tackle HTTPCORE-25 first > > > is an option. Would you be interested in giving us a helping hand > > > developing / testing a non-blocking HTTP connection manager? > > > > > Let me take a look at this and see if I can handle it, as its of high > > importance to us. If I am successful, I will share any code back with you. > > > > Hi Asankha, > > Feel free to take the lead in this work and will happily support you in > any way I can. At the very least I can promise to do code reviews, give > you some feedback and suggestions, and commit the code once we are all > more or less happy with the result. > > > > HttpCore NIO has been designed to work with any arbitrary SocketChannel, > > > so adding SSL layer security should not be difficult. All it takes is > > > making sure the I/O reactor instantiates the appropriate channel when > > > connecting to a remote host or listening for incoming connections. The > > > best approach to achieve this would be to use the good ol' factory > > > pattern > > > > > I think there is more to do when using SSL with NIO. Check this -> > > http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#SSLENG > > They state why a SSLSocketChannel class is not available with the JDK. > > My understanding is that we need to tackle this with the > > NHttpServiceHandler and NHttpClientHandler and use the SSLEngine class > > provided by the JDK to decode the byte buffers read from the NW into the > > application. > > Yes, you are right. I messed up. I assumed SSLEngine could be used to > decorate any socket channel interface but my assumption proved wrong. My > bad. I appears the non-blocking SSL support will require quite a bit of > work. Essentially is takes an additional filter between the I/O reactor > and the protocol handler. I'll start looking into that on the weekend. > > Cheers, > > Oleg >
Hi Asankha, I do not know if you are still evaluating HttpCore NIO or not, but I thought I should keep you in the loop just in case and let you know I had started working on adding SSL support [1]. I also would like to simplify the client-side API in the process and try to reduce the amount of plumbing code required for it. This is likely to entail some API changes and to break compatibility with ALPHA3. If you are not working directly with code in the trunk you should not be affected. I will republish the snapshots only when the trunk stabilizes and HTTPCORE-26 is resolved. Cheers Oleg [1] https://issues.apache.org/jira/browse/HTTPCORE-26 > > > Please go ahead and open a feature request in JIRA. Alternatively you > > > may just want to subclass the default I/O reactor impls and to override > > > #connect() and #listen() methods. > > > > > I will wait for you reply to see how we should raise the JIRA > > > > thanks > > asankha > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
