On 20/04/2013 2:33 a.m., Loïc Blot wrote:
> Hi,
> i'm using Squid 3.2.9 version and i want to explain you a configuration
> check which is missing and generate a bug for transparent/intercept
> configurations.
>
> I was using this http_port configuration earlier:
> http_port 3128
> http_port 3128 intercept (and also test with transparent)
>
> As i see, squid intercept/transparent mode doesn't work if the port is
> the same. If we (auto)configure proxy, no problem, but with transparent
> proxying, squid refuses connections and in intercept mode, 400: BAD URL
> is returned.
>
> For some specific applications, i need transparent proxying to work.
> Then i tried to change intercept port to 3129. And there, it works !
>
> If i try this configuration (only this line):
> http_port 3128 intercept
>
> Normal proxy traffic doesn't work anymore.
>
> There is two possible cases to resolve this problem:
> * Squid must understand if traffic is redirected or is a normal proxy
> traffic on intercept listening port
Not possible. Traffic on port 80 and port 3128 are different value
meanings in same syntax fields. The "intercept" config flag tells Squid
what syntax to parse along with whether to perform NAT lookups and
several other operations that are to be run specifically on intercepted
traffic and not other traffic.
When administrator tells Squid to parse format-80 on traffic arriving
to port 3128 Squid obeys.
> * Squid must refuse configuration when same http_ports are declared with
> different modes
You wish your live production server to cease service completely and DoS
all your clients if you make a small configuration mistake?
The current behaviour is to configure, with visible warnings when the
second port is unable to be opened (3128 already open by Squid in
non-intercept mode) . See your cache.log or syslog messages files for
complaints by Squid about port 3128 already being open.
Amos
Received on Fri Apr 19 2013 - 15:10:10 MDT
This archive was generated by hypermail 2.2.0 : Fri Apr 19 2013 - 12:00:06 MDT