On 30/11/10 20:33, Eric Vance wrote:
I have also had this issue. I was able to get the headers both going
through squid and not. I noticed a few key differences (but skip to
the end because I found the offending difference).
Request Header without Squid:
**************************************************************************************
GET http://broadband.espn.go.com/espn3/auth/userData?format=json&page=index
HTTP/1.1
Host: broadband.espn.go.com
Connection: keep-alive
Referer: http://espn.go.com/espn3/index
Accept: */*
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: SWID=C2085447-B5B5-4B68-9A02-97B9BEB8AC0C; userAB=C;
ESPN360beta=betaSet;
DE2=KioqOyoqKjtyZXNlcnZlZDticm9hZGJhbmQ7NTs0OzQ7MDswMDAuMDAwOzAwMDAuMDAwOzk5OTs1MzgzOzM0MDM7MDsqKjs=;
CRBLM=CBLM-001:; DS=PzswOz87; CRBLM_LAST_UPDATE=1291054796;
s_vi=[CS]v1|2679F7630516263D-60000198C0083F11[CE];
espnAffiliate=invalid;
s_pers=%20s_c24%3D1291061231070%7C1385669231070%3B%20s_c24_s%3DLess%2520than%25201%2520day%7C1291063031070%3B%20s_gpv_pn%3Despn3%253Ainvalid%253Aindex%7C1291063031109%3B
***************************************************************************************
Request header after Squid:
***************************************************************************************
GET /espn3/auth/userData?format=json&page=index
HTTP/1.0
Host: broadband.espn.go.com
Referer: http://espn.go.com/espn3/index
Accept: */*
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.5
17.44 Safari/534.7
Accept-Encoding: identity
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: SWID=C2085447-B5B5-4B68-9A02-97B9BEB8AC0C; userAB=C;
ESPN360beta=betaSet;
DE2=KioqOyoqKjtyZXNlcnZlZDticm9hZGJhbmQ7NTs0OzQ7MDswMDAuMDAwOzAwMDAuMDAwOzk5OTs1MzgzOzM0MDM7MDsqKjs=;
CRBLM=CBLM-001:; DS=PzswOz87; CRBLM_LAST_UPDATE=1291054796;
s_vi=[CS]v1|2679F7630516263D-60000198C0083F11[CE];
espnAffiliate=invalid;
broadbandAccess=espn3-false%2Cnetworks-false;
s_pers=%20s_c24%3D1291092114183%7C1385700114183%3B%20s_c24_s%3DLess%2520than%25201%2520day%7C1291093914183%3B%20s_gpv_pn%3Despn3%253Ainvalid%253Aindex%7C1291093914212%3B;
lang=en; s_sess=%20s_cc%3Dtrue%3B%20s_omni_lid%3D%3B%20s_sq%3D%3B%20s_ppv%3D16%3B;
PREF=f2=8000000;
Via: 1.0 ph:3128 (squid/2.7.STABLE9)
X-Forwarded-For: 127.0.0.1
Cache-Control: max-age=259200
Connection: keep-alive
***************************************************************************************
I manually issued this request changing one thing at a time until I
found the breaking item. When I removed this line from the Squid
version the response came back without the redirect (and I assume
would then work correctly):
X-Forwarded-For: 127.0.0.1
D**m, suspected as much when that IP came back in your broken reply
javascript.
So, I guess the questions are:
1. Is this line necessary?
Yes and no.
Yes, ... because XFF is important for tracking network bugs down and
informing the origin client IP. As you noticed this is one site which
uses it to produce per-user content display.
No, because 127.0.0.1 is a useless thing to be sending in there as the
first entry. It is an artifact of the way your particular requests went
to Squid.
2. Can it safely be removed?
Yes. If you are willing as the squid admin to shoulder all the blame for
any attacks made through your proxy.
3. How can it be removed?
In 2.7 configure: forwarded_for off.
There is something else you can do now that you know what and where the
problem is. You can pass this same report on to the webmaster of that
site. They are trusting the XFF trail too much.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.9
Beta testers wanted for 3.2.0.3
