Hi Julius, > As we get closer to the 4.0 release,
That's what I call a forward-looking statement. We're weeks away from even getting a grip on connection management, let alone from an HttpClient 4.0 that passes our internal reviews for an alpha1 release. > I have one "titanic + iceberg" feeling. Which one is us? > HTTPCLIENT-613 "https should check CN of x509 cert" I have no problem at all to make the default behavior strictly compliant with the specification, as long as it is easy to change. We're shipping HttpClient 3.0 with the RFC2109 cookie spec as default although many web sites require the browser compatibility spec to function properly. > I have this funny feeling that a lot of SOAP, REST, WS-*, and whatever > else people call server-to-server HTTP is going to go *splat* when > httpclient-4.0 starts making its way into JBoss, Websphere, Weblogic, > Axis, and all those other stacks. Sounds like a dream come true. The "making it's way" part of course ;-) As Odi pointed out, HttpClient 4 will not be a drop-in replacement. And nobody (running a serious risk) will be stupid enough to just roll out a completely new version of a J2EE platform or web services stack without testing their applications thoroughly. Problems will be detected in testing, and then people will decide whether to fix their DNS/hostname/certificate setup or whether to customize the behaviour of HttpClient. My bet is on the latter, but at least they'll know what they're doing. > Just before 4.0 has its first RC, I think we should prepare for this > issue on the wiki and even on the main webpage. I think you're overestimating the impact of TLS/SSL certificate verification. Have you compared the API of HttpClient 3 with what's in HttpCore? We're not only changing all package names, we've also removed HttpMethod which was at the center of the HttpClient 3 API. Trust me, by the time people have adapted their code to the new API, setting a different CN verification policy will be a trifle for them. A code migration guide would be much more important for the current user base, but I'm not going to put much effort into that until the HttpClient API stabilizes. Maybe by the time we're heading up to alpha3. I don't expect anybody to start a migration to alpha1. We can be glad if they even look at it to assess the potential effort. > ================================================= > FAQ - My "https://"; connections worked great with httpclient-3.x, but > ever since I upgraded to httpclient-4.x, my https connections are > broken with this error message: FAQ - I have an application that runs great with HttpClient 3.x, but when I compile it against HttpClient 4.0, the compiler cancels after 100 errors, and they all read "cannot find symbol" for classes in org.apache.commons.httpclient. > People were talking about "scheme" on this thread recently. Can we > provide the following two schemes right out of the box? We're far away from talking defaults. If any, I would suggest defaults that either adhere strictly to specifications or else map to JVM settings. > https-no-host-verify:// > https-completely-insecure:// I think it would be much better to have a good SSL guide that tells people how and why to set up such schemes themselves. A default, if we provide one, should map to the SSL socket factory of the JVM and perform CN checks as strictly as we can make them. > We provide this scheme only as an evil temptation for you to resist. That's a funny thing to write, and I guess I used to think so myself. But I have become much more pragmatic. If we don't want them to use it, we shouldn't put it in by default. That will keep more people from abusing the code as any warning. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
