On Thu, 2012-09-06 at 10:12 -0400, Daniel Kulp wrote:
> On Sep 6, 2012, at 9:40 AM, Oleg Kalnichevski <[email protected]> wrote:
> > On Wed, 2012-09-05 at 10:55 -0400, Daniel Kulp wrote:
> >> On Sep 5, 2012, at 9:35 AM, Alessio Soldano <[email protected]> wrote:
> >> 
> >>> On 09/04/2012 09:03 PM, Daniel Kulp wrote:
> >>>> 
> >>>> That said, there is still a bit of work todo:
> >>>> 
> >>>> 1) Proxy support - haven't looked into this at all yet.   Hard for me to 
> >>>> test as well as I don't have any sort of proxy setup anywhere.  I may 
> >>>> need to look into how to setup a simple proxy to dig into this.
> >>> 
> >>> Not sure if this would be the best option for you, but some time ago I
> >>> wrote some JBossWS tests related to http proxy configuration by using
> >>> LittleProxy [1], perhaps it's convenient here too.
> >>> 
> >>> [1] http://www.littleshoot.org/littleproxy/ 
> >> 
> >> Cool. I see they just started a vote for 0.5 so if I wait a day or three, 
> >> I can just start with the newer version.  :-)
> >> 
> >> Thanks for the pointer.
> >> 
> >> Dan
> >> 
> > 
> > I personally use Squid [1] running locally in non-daemon mode to test
> > HttpClient against. It is one of the most widely used proxies around.
> 
> 
> I was originally looking at this, but there is a big disadvantage:  it's 
> external to the build.   The nice thing about the littleproxy thing is in 
> your junit tests, you can pop up a proxy on any port, use it, bring it down, 
> etc… just like any other service we may be using.   It would work on every 
> developers machine.  
> 
> Right now, we have ZERO coverage of the proxy support in CXF, even for the 
> HttpURLConnection based transport.   With the little proxy thing, I'm hoping 
> to rectify that.    That said, I don't think it provides all the various 
> possible proxy situations that squid can, but at this point, some tests are 
> better than none.   :-)
> 
> 

This is certainly a very valid point. Actually we are in the same boat.
Close to zero coverage of proxy code. And we have all the building
blocks necessary to put together a full blown caching proxy. The trouble
is that the _real_ troublemaker is never the proxy itself. In most cases
proxies are almost transparent to the client. The real ugly b**ch is
always a combination of HTTP proxy and authentication (either on the
proxy or the target side), especially NTLM, which is not very easy to
emulate.

Oleg


Reply via email to