RE: [squid-users] 304 response preventing site from loading

From: Paul Freeman <paul.freeman_at_eml.com.au>
Date: Thu, 30 Sep 2010 13:24:35 +1000

Shawn
I have seen Amos' reply regarding a possible bug in the version of squid you
are using and his suggestion to upgrade and try again.

After seeing your question, I did some testing using different versions of
squid I have access to - Squid 3.1.8 and Squid 2.6stable18.

Both squid installations are using authentication (Kerberos/NTLM for 3.1.8
and ntlm/basic for 2.6stable18) and are running on Ubuntu - 3.1.8 on Ubuntu
10.04LTS and 2.6stable18 on Ubuntu 8.04LTS.

Transparent interception is _not_ being used in either installation.

I tested using Firefox v 3.6.3 and found that going direct (not using squid)
works OK (approx 30 sec page load) but going via squid 3.1.8 or squid
2.6stable eventually works but is very slow (approx 4-5minutes to load the
entire page contents).

Basically, I have found these squid versions both work and load the page
successfully but for me, the page is slow to load when using squid compared
with going direct. I have investigated this further and the problem may be
related to some aspect related to networking on my squid server OS (linux)
rather than squid but I am not sure.

For those who are interested, please read on ... (a bit long) :-)

Regards

Paul Freeman

The discussion below refers to my investigation using squid 3.1.8. It is
running on Ubuntu 10.04LTS and was compiled from a source package created by
Amos Jeffries (thanks Amos). The client workstation is running Windows XP
SP3.

Doing some wireshark packet traces of the traffic leads me to think the
slowness is in retrieving two urls:
http://www.dushkin.com/web-cgi/olc/nytfeed.pl?DCID=984&N=3
http://www.dushkin.com/web-cgi/olc/gencurrentnew.pl?DCID=984&N=3

Both the GET requests for these urls get 302 re-direct responses as follows
(same order as urls above):
http://www.mhcls.com/cls/web-cgi/olc/nytfeed.pl?DCID=984&N=3
http://www.mhcls.com/cls/web-cgi/olc/gencurrentnews.pl?DCID=984&N=3

Requests to these re-direct urls also receive 302 re-direct responses as
follows (same order as urls above):
http://www.mhhe.com/cls/?DCID=984&N=3
http://www.mhhe.com/cls/?DCID=984&N=3

It is this last url (http://www.mhhe.com/cls/?DCID=984&N=3) that seems to
take a long to retrieve by squid.

I originally thought the slowness may have to do with the HTTP/1.1 feature of
Transfer-Encoding: chunked as I have come across this in some other work I
have been doing recently.

This header is included in the www.dushkin.com and www.mhcls.com 302
re-direct responses. I noticed in the header the word chunked is all lower
case. This does not appear to be in violation of the HTTP/1.1 spec but some
versions of squid use a case sensitive compare for "Chunked" (capital C) and
thus do not match on "chunked". IN some instances and squid versions, the
Transfer-Encoding: chunked/Chunked header can cause squid to not be able to
determine when all the data to fulfil the GET request has been supplied and
so it waits. Eventually the web server replying to the GET request will
timeout the connection (timeout various depending on the web server but can
be of the order of a minute or more), sending a TCP RST. Search the
squid-users mailing list for more info on this one.

However on further investigation, I don't think this is the case in this
instance. For some reason, the squid GET request to www.mhhe.com (IP
12.26.55.139) takes a long time to be completed - approx. 2 minutes. Some
data is returned quickly but then there is a period where on my squid server
I see a TCP Previous Segment lost then squid server sending Dup ACKs to
www.mhhe.com and www.mhhe.com sending TCP Retransmissions for the same
segment. The Retransmission RTTs to ACK the one segment are at 0.2,4,8,16,32
and 60 seconds. After that segment has finally been received, the rest of
the data is received OK.

The reply headers from the GET to www.mhhe.com are as follows:

HTTP/1.0 200 OK
Server: MHttpd/3.2 (UAI; sparc-solaris2.6; Meta-HTML/5.06)
Date: Thu, 30 Sep 2010 00:06:25 GMT
Expires: Wed 29 Sep 2010 00:06:25 GMT
Last-modified: Thu Sep 2010 00:05:25 GMT
Content-length: 13858
Meta-HTML-Engine: MHtppd/3.2 (UAI; sparc-solaris2.6; Meta-HTML/5.06)
Content-type: text/html

There are two GET requests for the url http://www.mhhe.com/cls/?DCID=984&N=3
and each takes approx. 2 minutes to complete which accounts for the approx. 4
minute delay in loading the page.

I am not sure what is causing this but it appears at first glance to be
related to a networking issue on the host squid server OS.

Going directly using the same Workstation/Browser/LAN/Firewall/Internet
connection combination does not show the same delay - only approx 29 seconds
to load. I still see a TCP Previous Segment lost and the Dup ACKs and TCP
Retransmissions when going direct but there are fewer TCP Retransmissions
(2-3 compared with 6-7) and hence the quicker reply.

The IP address of highered.mcgraw-hill.com is 204.8.133.213 while the IP
addresses of www.dushkin.com, www.mhcls.com and www.mhhe.com are the same -
12.26.55.139.

If anyone has any ideas or suggestions, I would be glad to hear them.

> -----Original Message-----
> From: Shawn Wright [mailto:swright_at_shawnigan.ca]
> Sent: Thursday, 30 September 2010 9:26 AM
> To: squid-users_at_squid-cache.org
> Subject: [squid-users] 304 response preventing site from loading
>
>
> We have encountered a site which does appear to like going through our
> squid proxy, either regular or transparent mode. I have contacted the
> company, but was hoping someone here could quickly try this site and
> tell me if it works through your squid proxy.
>
>
> http://highered.mcgraw-
> hill.com/sites/0072421975/student_view0/index.html
>
>
> It is a school textbook site, and the menus will not load when going
> through proxy.
>
>
> We have a transparent proxy which uses WCCP2 from a Cisco Cat6500 to
> redirect the packets from the clients. I have also disabled wccp and
> tried a manual proxy config from the browser. The only thing that works
> is a SNAT from the client through our firewall, which isn't a solution
> for us.
>
>
> The squid log shows: (squid 2.6-20)
>
>
>
> 1285802182.732 403 10.3.0.144 TCP_REFRESH_HIT/304 186 GET
> http://highered.mcgraw-
> hill.com/sites/0072421975/student_view0/index.html -
> DIRECT/204.8.133.213 -
> 1285802182.906 160 10.3.0.144 TCP_REFRESH_HIT/304 185 GET
> http://highered.mcgraw-hill.com/olcweb/styles/v2/wheat/css.css -
> DIRECT/204.8.133.213 -
> 1285802182.909 166 10.3.0.144 TCP_REFRESH_HIT/304 186 GET
> http://highered.mcgraw-hill.com/olcweb/styles/shared/shared.css -
> DIRECT/204.8.133.213 -
> 1285802182.910 159 10.3.0.144 TCP_REFRESH_HIT/304 186 GET
> http://highered.mcgraw-hill.com/olcweb/styles/shared/v2_dhtml.js -
> DIRECT/204.8.133.213 -
> 1285802182.912 164 10.3.0.144 TCP_REFRESH_HIT/304 186 GET
> http://highered.mcgraw-hill.com/olcweb/styles/shared/common.js -
> DIRECT/204.8.133.213 -
> 1285802182.915 162 10.3.0.144 TCP_MISS/302 544 GET
> http://www.dushkin.com/web-cgi/olc/nytfeed.pl?DCID=984&N=3 -
> DIRECT/12.26.55.139 text/html
> 1285802182.916 163 10.3.0.144 TCP_REFRESH_HIT/304 186 GET
> http://highered.mcgraw-hill.com/olcweb/styles/shared/v2_functions.js -
> DIRECT/204.8.133.213 -
> 1285802182.917 162 10.3.0.144 TCP_REFRESH_HIT/304 184 GET
> http://highered.mcgraw-hill.com/olcweb/styles/shared/copyright.gif -
> DIRECT/204.8.133.213 -
> 1285802182.923 169 10.3.0.144 TCP_MISS/302 558 GET
> http://www.dushkin.com/web-cgi/olc/gencurrentnews.pl?DCID=984&N=3 -
> DIRECT/12.26.55.139 text/html
> 1285802183.071 163 10.3.0.144 TCP_REFRESH_HIT/304 185 GET
> http://highered.mcgraw-
> hill.com/olcweb/styles/shared/branding/003366_nopowerweb.gif -
> DIRECT/204.8.133.213 -
> 1285802183.074 168 10.3.0.144 TCP_REFRESH_HIT/304 186 GET
> http://highered.mcgraw-
> hill.com/sites/dl/free/0072421975/banner/mader_inquiry.gif -
> DIRECT/204.8.133.213 -
> 1285802183.081 163 10.3.0.144 TCP_REFRESH_HIT/304 184 GET
> http://highered.mcgraw-
> hill.com/olcweb/styles/v2/wheat/nav_divider_small.gif -
> DIRECT/204.8.133.213 -
> 1285802183.082 172 10.3.0.144 TCP_REFRESH_HIT/304 184 GET
> http://highered.mcgraw-hill.com/olcweb/styles/v2/wheat/nav_top.gif -
> DIRECT/204.8.133.213 -
> 1285802183.084 162 10.3.0.144 TCP_MISS/302 498 GET
> http://www.mhcls.com/cls/web-cgi/olc/nytfeed.pl?DCID=984&N=3 -
> DIRECT/12.26.55.139 text/html
> 1285802183.087 175 10.3.0.144 TCP_REFRESH_HIT/304 185 GET
> http://highered.mcgraw-hill.com/olcweb/styles/v2/wheat/nav_closed.gif -
> DIRECT/204.8.133.213 -
> 1285802183.088 164 10.3.0.144 TCP_MISS/302 498 GET
> http://www.mhcls.com/cls/web-cgi/olc/gencurrentnews.pl?DCID=984&N=3 -
> DIRECT/12.26.55.139 text/html
> 1285802183.094 158 10.3.0.144 TCP_REFRESH_HIT/304 185 GET
> http://highered.mcgraw-
> hill.com/olcweb/styles/shared/server_constants.js -
> DIRECT/204.8.133.213 -
> 1285802183.256 158 10.3.0.144 TCP_REFRESH_HIT/304 184 GET
> http://highered.mcgraw-hill.com/olcweb/styles/shared/spacer.gif -
> DIRECT/204.8.133.213 -
> 1285802183.264 164 10.3.0.144 TCP_REFRESH_HIT/304 185 GET
> http://highered.mcgraw-hill.com/olcweb/styles/shared/nytimeslogo.gif -
> DIRECT/204.8.133.213 -
>
>
>
>
>
>
>
>
>
> Shawn Wright
> I.T. Manager
> Shawnigan Lake School
>
> Please direct requests for support to helpdesk_at_shawnigan.ca
>
>
>
> __________ Information from ESET Smart Security, version of virus
> signature database 5490 (20100929) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
 

__________ Information from ESET Smart Security, version of virus signature
database 5490 (20100929) __________

The message was checked by ESET Smart Security.

http://www.eset.com
 
Received on Thu Sep 30 2010 - 03:24:06 MDT

This archive was generated by hypermail 2.2.0 : Thu Sep 30 2010 - 12:00:04 MDT