[squid-users] RE: EXTERNAL: Re: [squid-users] Clients issuing URLs directly to Squid port, URL rewrite to t

> Is this a further complication on top of the other thread we are
> discussing SSL links?

Yes ... all boiling back to us not being allowed to alter proxy settings on the PC. They want us to install a proxy, but won't let us change proxy settings, go figure. My original thought had been, ok, we'll redeploy the web services on e.g. port 8081 on the server (they'll let us do that), then use the equivalent of iptables on the PC to redirect outgoing calls to 8081 to 3128. But, to my surprise (I'm a Linux guy), Windows doesn't /have/ anything like iptables built in (not even the server versions, unbelievably), and you can't redirect ports without writing a network driver or buying e.g. a bandwidth-shaping app. Not an option for us.

Hence the rube Goldberg I described below. I'm being told that there are no URLs buried in the XML/headers, nor in any replies coming back, that the only thing the web service URL is used for is straight HTTP addressing.

These are .Net apps, and I'm being told there might be a way to set proxying just for the app, in what sounds like a .Net deployment descriptor of some kind. Hopefully that pans out, so I don't have to tempt Murphy on this.

Thx for answering!

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Wednesday, August 04, 2010 7:37 PM
To: Bucci, David G
Cc: squid-users_at_squid-cache.org
Subject: EXTERNAL: Re: [squid-users] Clients issuing URLs directly to Squid port, URL rewrite to t

On Wed, 04 Aug 2010 12:54:24 -0400, "Bucci, David G"
<david.g.bucci_at_lmco.com> 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
Received on Thu Aug 05 2010 - 09:14:45 MDT