cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: CXF and HTTP proxy properties
Date Fri, 15 Oct 2010 15:33:28 GMT
On Friday 15 October 2010 3:53:54 am Guillaume Sauthier wrote:
> > So, I come here to discuss this point.
> > 
> >> Could it be possible (currently I'm not sure, but maybe as an evolution)
> >> to provide the proxy configuration as some kind of global variable for
> >> all the services (maybe as a per-bus configuration), but with support
> >> for nonProxyHost (or the like) ?
> >> 
> >> WDYT ?
> > 
> > I think this could be done via an interceptor as well.   An interceptor
> > run very early in the chain could grab the conduit and reconfigure the
> > proxy stuff fairly easily based on the URL it's going to hit.
> > 
> > The other way to handle this, which is how JBoss does this I believe, is
> > to set their own Configurer on the bus that wrappers the original one
> > and has configureBean methods that, if the bean is an HTTPConduit,
> > completely configures the conduit based on information from the app
> > servers configs. Really, that is the ideal way for app servers and
> > containers and such to configure the various parts of CXF as CXF uses
> > that mechanism to configure itself.
> OK I get your point.
> But how this solution (not interceptor based) can handle the issue of
> the client changing the endpoint address after it has retrieved the port
> proxy ?
> After reading the code, it seems that the real URL is finally known
> during HTTPConduit.prepare(Message) (more precisely in
> HTTPConduit.setupUrl() ), so using an Interceptor will probably not help
> :'( Then the URL is passed to an HttpConnectionFactory along with a Proxy
> instance (created from the proxy information in the Conduit's config)
> After some more thinking I think my solution will be something like:
> * Configure the HTTPConduit using the Configurer extension to propagate
> the System HTTP proxy properties

Yep, although ideally, HTTPConduit would call client.isSetProxyServer() and if 
false, use the system properties.   Then nothing to configure.   A patch for 
that would be more than welcome.  :-)

> * Provides a new HttpUrlConnectionFactory that will act as  a proxy and
> nullify the Proxy reference (given as param) if the URL endpoint is one
> of the hosts filtered by http.nonProxyHosts before delegating to the
> real HttpUrlConnectionFactory

I really wouldn't go there.   If you look at what I'm doing on the branch for 
async work, the HttpUrlConnectionFactory isn't used for that since the http-
client stuff doesn't use the HttpURLConnection object.

Actually, an interceptor CAN configure an HTTPClientPolicy.   I can do 
something like:

HTTPClientPolicy pol = new HTTPClientPolicy();
pol.setABunchOf Things();
message.put(HTTPClientPolicy.class, pol)

and the HTTPConduit will intersect that with the one it has to create an 
effective HTTPClientPolicy that is used.   Thus, you can set a proxy from an 
interceptor that way and  not  really modify the CXF code at all.

HOWEVER, my suggestion would be to:
1) Add a nonProxyHosts element to the HTTPClientPolicy so it can be 

2) Update the  getProxy(..) call in HTTPConduit to take the URL as a param and 
have it call the isSet things and such to do the logic.   Use the sysprops if 

Then attach the above to a JIRA as a patch and we'll get it committed real 
soon.  :-)


> // Theses 2 first points could be contributed back directly to CXF
> * Indeed, for JOnAS I'll have to intercept the HTTPConduit creation with
> my own HTTPConduit subclass that will return my own
> HttpUrlConnectionFactory.
> // This last part could be introduced directly into CXF HTTPConduit if
> you're ok with this (directly using the
> FilteringNonProxyHostsHttpUrlConnectionFactory - quite long name BTW :) )
> WDYT ?
> --G

Daniel Kulp

View raw message