Richard Wall wrote:
On Sat, Jan 9, 2010 at 1:10 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
I would not worry about that. P2P apps which use port 80 usually have other
methods of connecting. Particularly their own dedicated protocol ports.
Leave those open and they work better.
The apps which do not use port 80 for HTTP properly (ie doing correct HTTP
tunneling) are in violation of web usage standards. Your contracts should
not allow you to be penalized for providing a properly working web proxy to
your clients.
Thanks Amos,
Sorry for not replying sooner. I agree and I think I was wrong about
the proportion of non-http traffic. The problem lay elsewhere.
If you must look at it, then the workaround hack of identifying packets data
content has to be done in the iptables routing levels. This is a tricky
problem since there is no guarantee that the needed data is in the first
packet of a connection. Once packets enter Squid its too late to bypass.
Yeah, we're using a Foundry ServerIron L7 switch which seems to have a
facility to reconstruct the http headers and use those in routing
policies. Sounds like magic to me, but if I manage to get that
working, I'll report back.
I'm also still interested in the wccp_return_method as a way of
bypassing non-http traffic, but in a previous thread it seemed that
Squid doesn't support this yet:
* http://www.squid-cache.org/mail-archive/squid-users/200811/0130.html
* http://www.mail-archive.com/squid-users@xxxxxxxxxxxxxxx/msg63741.html
* http://old.nabble.com/WCCP-load-balancing-and-TPROXY-fully-transparent-interception-td20299256.html
Thanks for your help.
-RichardW.
Squid passes those configuration options on to the router. But I can't
see anything special being done about packets. Once the TCP link is
accepted Squid handles it fully, either servicing the request or
returning an HTTP error page. Squid does not even accept packets for
ports it can't service.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE21
Current Beta Squid 3.1.0.15
