On Wed, 04 Aug 2010 12:54:24 -0400, "Bucci, David G" <david.g.bucci@xxxxxxxx> wrote: > Hi, all - I won't go into full details, but we have a situation where we > have very little control over a certain bespoke application, whose web > service calls we want to proxy through a local Squid instance (refer to my > recent exchange on using Squid as a poor-man's SSL VPN). We can't > reimplement the application to respect or support proxy settings; about all > we can do is set the URLs that the application will use for its web service > calls. > > So I'm wondering if this scenario could be made to work, to force the > app's web service calls through a local Squid instance - assume we have 2 > web services, ServiceA hosted on ServerA, and ServiceB hosted on (wait for > it ...) ServerB; and we know that there are no duplicate service names, and > we can map from a service name to the correct server name hosting that > service. > > - Run Squid on the PC, on port 3128 > > - Configure the application to call http://localhost:3128/ServiceA or > http://localhost:3128/ServiceB > > - Via URL rewriting, rewrite the first call to http://ServerA:80/ServiceA, > and the 2nd call to http://ServerB:80/ServiceB > > - Have Squid perform its normal processing on the resulting request (in > this case, per the other email exchange, establishing an SSL connection, > using the user's certificate, to a cache-peer Squid instance on e.g. > ServerA, which will in turn call the web service ServiceA being hosted on > WebLogic on ServerA:80) > > > It boils down to whether Squid will accept an HTTP call directly to its > listening port, and if it does, will it shell to an URL rewriter to process > such a call. Yes. Not a good idea though. Non-browser agents more commonly use URLs in their extra headers and body content than browsers. This type of URL breaks things very easily with re-writing. > > Any thoughts appreciated, thank you. Is this a further complication on top of the other thread we are discussing SSL links? Amos
