Bug #1723
closedGoogle Adsense cookie crashes lighttpd
Description
It seems that Google Adwords cookie (utmz) when containing polish characters like (?, ?, ?) crashes lighttpd with this error:
http_req.c.284: (trace) parsing failed at token ( [1]), header: GET /grupy/kategoria/9/ciaza/?utm_source=adwords&utm_medium=cpc&utm_campaign=ciaza_forum_twoja_pierwsza_ciaza&gclid=CJrZsY6SxJQCFQuGugodAUXTFA
HTTP/1.0 Host: www.benc.pl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Referer: http://www.google.pl/search?hl=pl&q=ci%C4%85%C5%BCa+forum&btnG=Szukaj&lr= Cookie: PHPSESSID=c7e186b9c4d9067f4bf743b6db2f4382; __utma=92535822.3018116742044647000.1216201610.1216201610.1216201610.1; __utmb=92535822.1.10.1216201610; __utmc=92535822; __utmz=92535822.1216201610.1.1.utmcsr=adwords|utmgclid=CJPsgoWQxJQCFQoNZwod-3tTGQ|utmccn=ciaza_forum_twoja_pierwsza_ciaza|utmcmd=cpc|utmctr=ci|a%20forum Via: 1.1 www.sciaga.pl:80 (squid/2.6.STABLE20) X-Forwarded-For: 83.9.189.147 Cache-Control: max-age=259200 Connection: keep-alive
This is why: utmctr=ci|a%20forum
This is google's fault because they should escape the string inside val utmcrt so it would look like this (ci%C4%85%C5%BCa+forum) - they do this everywhere exept adwords.
Also this cookie works in apache web server (doesn't crash it) :)
I will write to google about this matter.
-- pawel
Updated by stbuehler almost 13 years ago
- Description updated (diff)
- Assignee deleted (
jan) - Priority changed from High to Normal
- Missing in 1.5.x set to No
%C4%85%C5%BC are all characters that are allowed, so they shouldn't be a problem. we had other reports of them being control chars (like %05), which we will never allow.
Updated by usego almost 13 years ago
stbuehler wrote:
%C4%85%C5%BC are all characters that are allowed, so they shouldn't be a problem. we had other reports of them being control chars (like %05), which we will never allow.
What's the purpose to make such strict checks against de-facto obsolete RFC? In real world google determines what is standard, not RFC. This is really huge issue as lost adword clicks due to 400 = lost real money. This issue prevents using unpatched lighttpd on production.
Updated by stbuehler almost 13 years ago
No, i do NOT change code just to workaround google bugs. Oh, and while we are at it: I don't like adwords.
if you think google practice sets the standards, then go use their software, but don't complain here.
Updated by sergey.b almost 13 years ago
stbuehler wrote:
%C4%85%C5%BC are all characters that are allowed, so they shouldn't be a problem. we had other reports of them being control chars (like %05), which we will never allow.
No, he stated that he got "utmctr=ci|a%20forum". I think it's the same problem as:
http://redmine.lighttpd.net/issues/2378
Updated by usego almost 13 years ago
stbuehler wrote:
No, i do NOT change code just to workaround google bugs. Oh, and while we are at it: I don't like adwords.
if you think google practice sets the standards, then go use their software, but don't complain here.
I was under impression that lighttpd is targeted to e-commerce sites too where Adwords are de-facto way of doing business. Sorry, I was wrong.
Updated by icy almost 13 years ago
Sergey, usego: have you tried contacting Google so they fix the cookies in Adwords? Because this is where the bug really is.
And regarding the last snarky remark: yes you were indeed wrong. Lighty is not targeted to E-Commerce sites. Lighty is not targeted to any specific kind of site in any way. Lighty is targeted for users who need a lightweight and fast webserver. Google does not determine what the standard is. The HTTP RFC is not de-facto obsolete.
Updated by gstrauss over 8 years ago
- Missing in 1.5.x changed from No to Yes
FYI: in lighttpd 1.4.40, you can now set server.http-parseopt-header-strict = "disable"
With the default (strict header parsing enabled), lighttpd 1.4.x will return 400 Bad Request for such a request.
Also available in: Atom