retitle 610199 polipo: may download same object in endless loop thanks Hi,
Here is a new, real-world example of this bug. But there was nothing logged in polipo.log this time. Request to upstream server sent by Polipo: > GET /urchin.js HTTP/1.1 > Host: www.google-analytics.com > User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.3) Gecko/20100101 > Firefox/10.0.3 > Accept: */* > Accept-Language: en-gb,en;q=0.5 > Accept-Encoding: gzip, deflate > Referer: [removed] > Connection: keep-alive > Response: > HTTP/1.1 200 OK > Content-Length: 6847 > Content-Encoding: gzip > Last-Modified: Thu, 19 Apr 2012 00:42:58 GMT > X-Content-Type-Options: nosniff > Date: Fri, 20 Apr 2012 12:23:45 GMT > Expires: Fri, 04 May 2012 12:23:45 GMT > Content-Type: text/javascript > Vary: Accept-Encoding > X-Content-Type-Options: nosniff > Cache-Control: max-age=1209600, public > Age: 40434 > Server: GFE/2.0 > The upstream server follows up with the request body, but before that arrives Polipo already tries to close the connection (and subsequent packets from upstream are responded to with RSTs) : > 00:38:30.110567 IP 188.220.33.66.46805 > 173.194.34.160.80: Flags [.], ack 1, > win 46, options [nop,nop,TS val 517949988 ecr 111225613], length 0 > 00:38:30.110705 IP 188.220.33.66.46805 > 173.194.34.160.80: Flags [P.], seq > 1:338, ack 1, win 46, options [nop,nop,TS val 517949988 ecr 111225613], > length 337 > 00:38:30.143951 IP 173.194.34.160.80 > 188.220.33.66.46805: Flags [.], ack > 338, win 239, options [nop,nop,TS val 111225649 ecr 517949988], length 0 > 00:38:30.146274 IP 173.194.34.160.80 > 188.220.33.66.46805: Flags [.], seq > 1:1411, ack 338, win 239, options [nop,nop,TS val 111225649 ecr 517949988], > length 1410 > 00:38:30.146356 IP 188.220.33.66.46805 > 173.194.34.160.80: Flags [.], ack > 1411, win 68, options [nop,nop,TS val 517949997 ecr 111225649], length 0 > 00:38:30.146534 IP 188.220.33.66.46805 > 173.194.34.160.80: Flags [F.], seq > 338, ack 1411, win 68, options [nop,nop,TS val 517949997 ecr 111225649], > length 0 > 00:38:30.146859 IP 188.220.33.66.46806 > 173.194.34.160.80: Flags [S], seq > 2109475568, win 5840, options [mss 1422,sackOK,TS val 517949997 ecr > 0,nop,wscale 7], length 0 > 00:38:30.147999 IP 173.194.34.160.80 > 188.220.33.66.46805: Flags [.], seq > 1411:2821, ack 338, win 239, options [nop,nop,TS val 111225649 ecr > 517949988], length 1410 > 00:38:30.148104 IP 188.220.33.66.46805 > 173.194.34.160.80: Flags [R], seq > 1730631505, win 0, length 0 > 00:38:30.149949 IP 173.194.34.160.80 > 188.220.33.66.46805: Flags [.], seq > 2821:4231, ack 338, win 239, options [nop,nop,TS val 111225649 ecr > 517949988], length 1410 > 00:38:30.150027 IP 188.220.33.66.46805 > 173.194.34.160.80: Flags [R], seq > 1730631505, win 0, length 0 > 00:38:30.150346 IP 173.194.34.160.80 > 188.220.33.66.46805: Flags [P.], seq > 4231:4474, ack 338, win 239, options [nop,nop,TS val 111225649 ecr > 517949988], length 243 > 00:38:30.150418 IP 188.220.33.66.46805 > 173.194.34.160.80: Flags [R], seq > 1730631505, win 0, length 0 > 00:38:30.176549 IP 173.194.34.160.80 > 188.220.33.66.46805: Flags [.], seq > 4474:5884, ack 338, win 239, options [nop,nop,TS val 111225680 ecr > 517949997], length 1410 > 00:38:30.176624 IP 188.220.33.66.46805 > 173.194.34.160.80: Flags [R], seq > 1730631505, win 0, length 0 > 00:38:30.178331 IP 173.194.34.160.80 > 188.220.33.66.46805: Flags [P.], seq > 5884:7225, ack 338, win 239, options [nop,nop,TS val 111225680 ecr > 517949997], length 1341 > 00:38:30.178367 IP 173.194.34.160.80 > 188.220.33.66.46805: Flags [F.], seq > 7225, ack 339, win 239, options [nop,nop,TS val 111225681 ecr 517949997], > length 0 To me this suggests Polipo doesn't like something in the HTTP response header. It then attempts to re-download the object to infinity. This is odd as the document is usually retrieved fine by Polipo on the first attempt. In this case when I noticed it happening and restarted the polipo process. By that time it had downloaded some 3+ GiB of unwanted data from Google (average 120kbps for 8 hours). The client host that made the HTTP request had long been powered off and was no longer connected to Polipo. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
