cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <>
Subject Http/s configuration Proposal
Date Wed, 30 May 2007 15:35:38 GMT

As you know there as been some work done to correct/enhance the use of 
in the Http modules. CXF-661, CXF-666, CXF-672.

In that effort, a significant change in the parameters for SSL/TLS was 
required. It
added a new

        setTLSServerParameters(TLSServerParameters params)

call in which the TLSServerParameters is more in-line with the JSSE, 
which is
used exclusively for SSL/TLS transports.  However, I kept the

      setSSLServer(SSLServerPolicy policy)

call in order to maintain and not to break any existing configurations both
Spring and programmatic. Analogous stuff was done for the client side.

However, I have deprecated "setSSLServer()" and everything else 
internally that is related
to it. That approach seems to be working. There seem to be some 
complaints about the
"deprecation" compiler warnings.

The question is for version 2.0, since we are moving from 1.x, do we 
want to eliminate the
old configuration all together? My feeling and some consensus relayed to 
me is "yes".

I propose that we do remove the "setSslServer()" and "setSslClient()" 
calls, and remove the
"SSLServerPolicy" and "SSLClientPolicy" elements from "security.xsd" .

This will force people to configure SSL/TLS using "TLSServerParameters" and
"TLSClientParameters" elements in "security.xsd" for spring 
configuration and
"setTLSServerParameters()" and "setTLSClientParameters()" calls for 

The next thing in the proposal to take care of the same time, is that 
there is an issue about
conflicts in SSL/TLS configuration, which is hard, if not impossible, to 
mitigate. This issue is that
there is a setTLSServerParameters() on the AbstractHTTPDestination and 
also on
the JettyHTTPServerEngine.

The problem is that the JettyHTTPServerEngine can get its TLS 
configuration from 2 places.
One being Spring configuration on bean name based on its implementation
and the other indirectly by the configuration of the HTTPDestination, 
because the destination
also holds a TLSServerParameters property.

This has consequences. The JettyHTTPServerEngineFactory creates 
JettyHTTPServerEngine which
basically holds a configured or SSLServerSocket 
on whether  the TLS configuration is present. The factory also caches 
these so that different
HTTPDestinations can be published on the same socket (port number).
This leads to problems in the such as:

    Endpoint.publish("https://localhost:9000/foo", ...);

when the second publish tries to "reconfigure" the retrieved already 
configured JettyHTTPServerEngine
due to the HTTPDestination trying to submit its TLSServerParameters to 
the already configured

The next item in the proposal is to remove SSL/TLS configuration (both 
Spring and programmatic)
from the HTTPDestination all together, and only be able to configure the 
SSL/TLS through the
JettyHTTPServerEngine. This is more in line with JSSE as HTTPS, is 
merely HTTP over a JSSE
configured Socket.

Several things would need to be done to get this to work well.
Remove the methods
from the AbstractHTTPDesination
and add:
    JettyHTTPServerEngine getJettyHttpServerEngine();
to JettyHTTPDestination so that programmatic configuration may happen 
like so:

EndpointImpl endpoint;
TLSServerParameters parms;


So, in summary of this entire proposal is the following:

1. Remove TLS configuration from the AbstractHTTPDestination.
2. Create an API to retrieve the JettyHTTPServerEngine from the 
3. Remove setSslServer() and setSslClient() from the APIs and remove 
    and SSLClientPolicy from the security.xsd.
4. Create a QName sutiable for Spring configuring the 
JettyHTTPServerEngine without
    using the internal fully qualified class name of its implementation.

I'll be working on this patch this afternoon. So please come up with any 
complaints, or suggestions (like for the QName Bean name for the 
spring configuration) ASAP.


View raw message