[squid-dev] on_unsupported_protocol rewrite to support tcp connection, relay

[Amos Jeffries]

On 27/03/2017 7:35 p.m., 钱国正 wrote:
>> If you want port 80 to just be relayed through - dont send it to Squid.
> 
>> You will probably be able to identify the DNS packets with your firewall
>> rules easier than Squid can tell it apart from a mangled HTTP message.
> 
> 
> 
> What I want to do is to use Squid ecap adaptation to modify some http response.
> But during the running time, I found that some famous mobile app using 80 port
> transport some unknown protocol (not http).

As you indicated in your last email there is no HTTP in this traffic
received. One of the things that means is that eCAP has nothing to work
with. There is definitely no HTTP response coming out of DNS servers.

Even if we let it through Squid you would still not be able to do
anything. You would barely even be able to see it happening in the logs.

As you may have noticed, the on_unsupported_protocol only has the
options of tunnel and reject ('respond' with an HTTP-format rejection),
nothing else - and those have to be decided before anything actually
happens with the traffic. The ACLs which it offers are also very limited
to the IP:port details and not much else.


> 
> What if the protocol is not http, but using 80 port, can squid relay it to its target server?
> 

That is the job of a TCP relay, Squid is an HTTP proxy. It is designed
in part to reject non-HTTP protocols.

Port 80 is a "reserved port". Like all such ports (0-1024) there is a
defined set of things which are possible, and the remainder is not. For
something to be possible on port 80 it has to have a structure and
behaviour matching HTTP/0.9, HTTP/1 or HTTP/2.

I'm aware that almost no software coming out of China these days works
properly when faced with real Internet networks - just because of how
they ignore reserved ports existing protocols. The solution to that is
*not* to make other software ignore the problem.

Amos