Paul,
Firstly, thanks for your very thorough testing! Your results mirror our experience - in one instance I did see the page load complete after some 5 minutes or more when going through proxy. Our server OS is Ubuntu 6.06LTS 32bit, kernel 2.6.15-26.
We did away with authentication in the summer after 10 years, as it caused too many problems with dumb apps and devices, and enabled transparent support with WCCP at that time, mainly for wireless devices.
This is the first site we've encountered so far that does not work. Many sites like itunes now work as we allow SSL traffic to be SNATed by our firewall, bypassing squid.
Shawn Wright
I.T. Manager
Shawnigan Lake School
Please direct requests for support to helpdesk_at_shawnigan.ca
----- "Paul Freeman" <paul.freeman_at_eml.com.au> wrote:
> 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 - 17:17:42 MDT
This archive was generated by hypermail 2.2.0 : Fri Oct 01 2010 - 12:00:04 MDT
