On Fri, 2012-09-07 at 12:53 -0400, Daniel Kulp wrote: > On Sep 6, 2012, at 9:33 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > > > On Wed, 2012-09-05 at 10:49 -0400, Daniel Kulp wrote: > >> Still not sure about the Proxy stuff at all, but that's likely because I > >> don't know much about Proxies at all. I'll likely need to look more into > >> what proxy stuff does on the wire. > >> > >> > > > > HTTP proxy support is not all that difficult _as long as_ support for > > complex HTTP authentication schemes is not required. If you need to > > support NTLM, Kerberos and the likes, expect a lot of grief and massive > > scalp hair loss. HttpAsyncClient provides full support for HTTP proxies > > and most commonly used authentication schemes but it is still considered > > BETA quality. If you want to re-use CXF authentication code HttpCore > > would give you more flexibility at the expense of having to write more > > custom code. Otherwise you might want consider trying out > > HttpAsyncClient. > > Looking at the proxy stuff, I really have no interest in re-inventing the > wheel on this. :-) Thus, it does look like going with HttpAsyncClient may > make the most sense. I started digging into this a bit, but ran into the > SSL configured "per connection factory" issue that I had before. HOWEVER, > this looks easily solvable with a simple patch to HttpAsyncClient. I've > logged the issue and attached it to: > > https://issues.apache.org/jira/browse/HTTPASYNC-25 > > Anyway, with the HttpAsyncClient stuff, the amount of code in CXF is > SIGNIFICANTLY reduced. A LOT less duplicated code. That's good. > However, we would need to have beta3 released pretty soon. Any ideas on > what the plans are for beta3? If beta3 won't be soon, I'll likely go with > what I have now and detect if the proxy is configured and force use of the > old transport if it is. If it will be release real soon, I'll pursue using > it. I do have all the systests/transports tests passing with the > HttpAsyncClient based stuff, including the new proxy based tests I added > yesterday. > > Thoughts? >
Hi Daniel I committed your patch with some minor tweaks. Please double-check. The fundamental problem here is that SSL connections set up on a per request (or per client basis) when kept alive by the connection manager can be later leased to another client thread with a different security context if one is not careful. We can cut as many BETA releases as needed and as often as needed. There have been not that many changes since BETA2, so I would not rush BETA3, but I'll call for a release vote as soon as you need it. What I am not really comfortable committing myself to is any time frame for a GA release. Oleg
