Colm, BTW: I believe 2.1.5 will also exhibit this.
Basically, what is the "policy" vs what is the "configuration"? With <2.1.3, both the protocol (http or https in the url) AND the TLS params were basically policy. Both had to be specified or not specified. With 2.1.3, in the https case, the TLS params became optional. If the protocol was https and no tls params, we just used the "defaults" of the JRE. Thus, it became more "configuration" than policy. However, if TLS stuff was configured, it wouldn't allow http. Thus it was a sort of mixed thing. This made it impossible to use a TLS configured client to talk to http services which we've had a bunch of users asking for. With 2.2 (and 2.1.5), it's really just configuration. The URL protocol dictates whether HTTP or HTTPs is used. That's the policy. If the protocol is https, the TLS params are the configuration for it, if specified. If you need to assert https, you would probably need to write an interceptor for it. OR, use WS-SecurityPolicy with TransportBinding/HttpsToken to assert it. Dan On Mon March 23 2009 8:33:30 am Colm O hEigeartaigh wrote: > Hi, > > I have a test-scenario with an endpoint with no TLS configuration, and a > client with a http conduit configured with a trust manager, e.g: > > <http:tlsClientParameters> > <cxfsec:trustManagers> > <cxfsec:certStore resource="... "/> > </cxfsec:trustManagers> > </http:tlsClientParameters> > > With CXF 2.1, an invocation fails with: > > Caused by: java.io.IOException: Illegal Protocol http for HTTPS > URLConnection Factory. > > In other words, the tlsClientParameters configuration is taken as > requiring that communication takes place with the endpoint over TLS, and > as the endpoint has no TLS configuration the invocation fails. > > However, with CXF 2.2 this invocation passes with no exception. Is this > a deliberate or inadvertent change? How does the client enforce that TLS > is used? > > Colm. -- Daniel Kulp [email protected] http://www.dankulp.com/blog
