RE: [SQU] Squid running on Red Hat 6.2 as transparent proxy locks up MSIE 5

> -----Original Message-----
> From: Stuart Parker [mailto:stuart@webobjectives.com.au]
> Sent: Monday, March 05, 2001 4:50 PM
> To: squid-users@ircache.net
> Subject: [SQU] Squid running on Red Hat 6.2 as transparent proxy locks
> up MSIE 5
>
>
> Hi there,
>
> We experienced a problem about 4 months ago whereby machines on 2
> seperate networks had a problem connecting to one of our web sites.
> The client machine if it was running Windows 95/98/NT and connecting
> with Internet Explorer would lock up. The cpu would be using 100% of
> the CPU and would not release it until IE was quit. In both cases it
> turned out that both sites had a transparent proxy enabled.
> Fortunately, we were able to communicate this to the network
> administrators of both sites and upgrading/flushing the cache
> appeared to fix the problem in both cases. However, the problem has
> returned on another network and we expect that it will keep occuring,
> so we would like to resolve the issue. The versions of Squid
> previously affected were Squid 2.2Stable3 and 2.4Devel1. The current
> network affected is transparently proxied by a machine running a Dell
> PowerApp.cache which AFAIK runs some version of squid on RH6.2.
>
>
> What I'm considering
> 1. In MSIE on the client, turning off "Use HTTP/1.1" in the Internet
> Options stops the lockup from occuring. Obviously we can't tell all
> of our visitors to do this when they visit our site though.

I suspect that it is the core problem. HTTP/1.1's persistent connection
semantics are different to those of HTTP/1.0. There are known
interoperability constraints, and while RFC 2616 may specificy them, IE
appears to expect HTTP/1.1 responses once you turn HTTP/1.1 on. (That's
an unrealistic expectation BTW).
 
> 2. Upgrading or flushing Squid also fixes the problem (could squid
> somehow simply get corrupted? If so any idea how to prevent it?).

No Idea. Some diagnostics might help..
 
> 3. Red Hat Linux 6.2 appears to be a consistent factor here. In
> section 14.5 of the FAQ I can't find anything specific to RH6.2 but I
> can't shake the feeling there is something here.
>
> 4. I have read about half-closed connections and how it is poor form,
> but I don't know which clients/servers this affects.
>
> 5. I read in the archives that squid does not support pipelining and
> does not act as a HTTP 1.1 proxy. I understand that this means that
> squid will chain a couple of requests together using keepalive but
> that's it. Is there any more documentation/notes on this and any
> potential issues it could cause?

Pipelining is when the client sends a second request on a persistent
connection before the response to the first request has finished
arriving (or even started). HTTP/1.1 is a significant upgrade on
HTTP/1.0 and I saw many user side problems (similar to what you
describe) with Squid and IE while stabilising the Transfer encoding
support. (Thats an important component of HTTP/1.1, and not production
ready).
 
> 6. I've tried to downgrade responses via the following line in our
> apache configuration file in the hope that this would force all
> connections into a 1.0 mode, but it didn't work.
> BrowserMatch "MSIE 5" nokeepalive downgrade-1.0 force-response-1.0

Your responses can be HTTP/1.1, and squid will correctly gateway those
to HTTP/1.0 syntax. A potential problem is that the client a) knows
there is no proxy involved, and b) is configured to use HTTP/1.1.
Mozilla had many problems sending HTTP/1.1 requests to HTTP/1.0 proxies
- so many in fact that they added an option to run in HTTP/1.0 mode with
older proxies.
 
> 7. If I send a HTTP/1.1 request from a machine which is inside the
> transparent proxys realm, it is downgraded to a 1.0 request silently
> (at least it appears in the apache logs as a 1.0 request). This leads
> me to think that some combination of squid running on RH6.2 as a
> transparent proxy is somehow misrepresenting a HTTP 1.1 request from
> MSIE and possibly causing some data to be malformed upon return which
> throws MSIE into some sort of infinate loop.

No. Squid makes a 1.0 request because thats all it understands. The
request should not be malformed as such, but it will only conform to the
HTTP/1.0 ruleset. (Not strictly true, squid has some 1.1 features, but
cannot request or answer as 1.1 because it's not complete).
 
> If anyone can help with some pointers or advice it would be greatly
> appreciated.

I believe the best answer is education:

"you" here means the network provider running the transparent proxy
a) transparent proxying is bad. It has many known issues, and it's
'features' can easily be reproduced by a combination of
autoconfiguration scripts (.pac files, wpad. domain entries) & a
firewall that blocks port 80 (or better yet, redirects the requests to a
web page that spells out the network policy and how to configure the
browser to use the autoconfig scripts/manual configuration).
b) Set the browsers up correctly. If you choose to run a transparent
proxy, it's your responsibility to have your users configure their
browsers correctly. (By running a transparent proxy you are interfering
with the assumptions made under TCP for end to end connectivity).
c) Under recent australian copyright law, transparent proxies may
actually be illegal (you are copying the users web request, which is
under their copyright, with out their express permission. I suggest that
by not configuring a proxy in their browser, they are denying permission
to copy the request.

Rob
 
> Thanks in advance,
> Stuart
> --
> ********************************
> Stuart Parker
> Web Objectives
> http://www.webobjectives.com.au
> stuart@webobjectives.com.au
> ********************************
>
> --
> To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
>
>

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html