Thanks, that helps a lot. That is actually close to what I'm planning to do...
However, do you think I can do all this by directly subclassing SSLClientIOEventDispatch? In other words, adding the CONNECT request to the newly created connection first, overriding/wrapping SSLClientIOEventDispatch.createConnection (but how do I get synchronously the result by submitting a request to that connection)? And let the SSL dispatcher do the SSL job after? I already made some slight changes (composite HTTP+HTTPS dispatcher, callback enhancement, backport to 4.0.1) and tested httpasyncclient. I'll push changes when/if my updates have the right level of quality regarding my network-related background (or just as a small contrib with warning :-). Cheers, Fabrice -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: mercredi 7 juillet 2010 12:31 To: HttpComponents Project Subject: RE: HttpCore NIO & SSL behind proxy On Wed, 2010-07-07 at 01:35 +0200, DELHOSTE Fabrice wrote: > Yes I'm aware of that - not my first time in this list and on this topic. Right. I forgot. > HTTP gateway pattern (latency, external backend, lot of users, etc) and more, > which makes NIO very relevant. > We were already using Httpclient and now httpcore nio (async client slightly > updated from yours) but I need SSL/proxy support... Adding support for the SSL tunneling most likely takes the following: (1) check whether the current request requires SSL tunneling (SSL + proxy mode) (2) if so, execute HTTP CONNECT to request a tunnel to the target server (3) if the proxy responds with 200 status code, a tunnel to the target server has been established (4) initialize SSL context as required and decorate the existing IOSession with SSLIOSession using that SSL context (5) stick the SSLIOSession instance to the original IOSession as an attribute. (6) (this is the tricky bit) the I/O dispatcher needs to be made aware of that fact that the i/o session has been upgraded to use SSL encryption. Most probably the dispatcher should check for the SSL session attribute, and if present, it should use extended methods of the SSLIOSession instance to ensure proper encryption / decryption of transported data. So, most certainly you will need a custom IOEventDispatch implementation. Hope this helps. Please also consider contributing some of your changes to the AsyncHttpClient back to the project. Cheers Oleg > ________________________________________ > From: Oleg Kalnichevski [[email protected]] > Sent: Wednesday, July 07, 2010 00:26 > To: HttpComponents Project > Subject: Re: HttpCore NIO & SSL behind proxy > > On Tue, 2010-07-06 at 23:28 +0200, DELHOSTE Fabrice wrote: > > Thx. > > > > I actually know a bit about the async client tryout. Btw I've also looked > > to Netty (any perf idea?) and used Mina in the past years... > > > > Even if it's helpful to understand what could be this high level package > > (pool, ...), I'd like to know more how I could implement/reuse some > > components for http core nio client to go first through a simple Http/s > > proxy (no authent, no chain, ...). > > > > Http Client supports this in a great seamless approach. Could you please > > point me into the right direction if any of this makes sense to reuse for > > http core nio (i've seen old discussion in the mailing list but no sample > > or details so far) ? > > > > Fabrice > > Fabrice > > What is the reason you want to be using NIO for client-side HTTP in the > first place? In my experience there is simply no real benefit of using > NIO over classic I/O for HTTP clients. NIO is slower and massively more > complex. It is just not worth it (unless used to manage outgoing > connections inside an HTTP proxy or an HTTP gateway). > > Oleg > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
