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
