Re: [squid-users] Squid 2.7stable7 and ESPN3

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Mon, 29 Nov 2010 02:12:55 +0000

On Sun, 28 Nov 2010 18:50:44 -0700, Jason Howlett <jason_at_jkhowlett.com>
wrote:
> On 11/27/2010 9:00 PM, Amos Jeffries wrote:
>> On 28/11/10 13:34, Jason Howlett wrote:
>>> Hello,
>>>
>>> I have an Ubuntu 10.0.4 server running Squid 2.7stable7 (I also tried
>>> Squid 3.0Stable19, but with the same result). I am using the default
>>> squid.conf file with the exception of adding an acl for my local
network
>>> and allowing access for that list. If I try to go to the following
URL:
>>> http://espn.go.com/espn3/index, Squid gets stuck in some sort of
>>> infinite loop where it tries to load that page over and over again.
This
>>> happens with both Firefox and Internet Explorer.
>>>
>>> I dug into the html source for the espn3 page and found the following
>>> line in the header: window.location.href = ud.redirect. If I comment
out
>>> that line then everything works correctly when I load my local copy of
>>> the page with the browser still configured to use the proxy server. I
>>> also found that if you set ud.redirect to something else
>>> (www.google.com, for example), then you get redirected there. If squid
>>> is bypassed, then everything works as expected.
>>>
>>> I don't know exactly what is happening under the javascript hood and
>>> what interaction with squid might be causing the infinite redirect.
Any
>>> help/suggestion is appreciated.
>>
>> There is zero interaction between Squid and javascript or any other
>> content in the page. Squid only deals with the HTTP mime headers
>> before the content starts.
>> This is either a javascript problem with the content coming out of
>> ud.redirect (whatever that is I could not be bothered reading the
>> 770KB of code in that page), or the followup response redirecting back
>> again.
>>
>> Amos
> I agree that there should not be any interaction between squid and the
> javascript and did not mean to infer such. Squid is most certainly
> involved in the behavior I am seeing. If I bypass Squid or even use
> tinyproxy then things work as expected. I have narrowed the problem down

> even further and will hopefully explain better what is happening.
>
> If I go to the following URL through Squid:
>
> http://broadband.espn.go.com/espn3/auth/userData?format=json&page=index
>
> I get this result:
>
> ud={'localAdAccountId':'', 'website':'', 'dma':'', 'isLoggedIn':'false',

> 'state':'', 'image':'', 'sso':'false', 'affvalid':'false',
> 'ip':'127.0.0.1', 'username':'null', 'name':'invalid',
> 'redirect':'http://espn.go.com/espn3/index', 'canaddsso':'false',
> 'ssoabuse':'false'}
>
> Notice that the redirect field is set to a value.
>
> If I go to the same URL but through tinyproxy (or bypass proxy
> altogether) I get this response:
>
> ud={'localAdAccountId':'null', 'website':'http://www.cox.net/',
> 'dma':'12', 'isLoggedIn':'false', 'state':'arizona', 'image':'cox.png',
> 'sso':'false', 'affvalid':'true', 'ip':'70.162.133.208',
> 'username':'null', 'name':'cox', 'redirect':'', 'canaddsso':'true',
> 'ssoabuse':'false'}
>
> Note here that the redirect field is null. Clearly Squid is doing
> something that changes the result of this query, but I have no idea what

> that is. I thought it might be returning a cached result, but clearing
> and rebuilding my cache didn't help.

So the server is producing garbage. You will need a trace of the request
headers going between Squid and the server versus browser straight to the
server.

Amos
Received on Mon Nov 29 2010 - 02:13:00 MST

This archive was generated by hypermail 2.2.0 : Mon Nov 29 2010 - 12:00:03 MST