Opened 9 years ago

#1185 closed defect (Fixed)

HTTP 204 Triggers Retry Flood/DOS

Reported by: erik Owned by: loafier
Priority: Very High Milestone:
Component: Polipo Version: 1.0
Severity: Keywords:
Cc: erik, qux, loafier Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Upon an origin server sending an HTTP 204 response, two chained instances of polipo (one having the other set as its parentProxy) may continually re-request the resource even after the http client has terminated.

This bug is present in the current version from git (commit 11af3996e126fe9042f869869fc1c7dbcdee3546), as well as earlier versions.

Here is the setup/replication, in detail:

env -i make PREFIX=$HOME/polipo-install LOCAL_ROOT=$HOME/polipo-install/www install

# Ensure defaults apply
[ -f ~/.polipo ] && mv ~/.polipo ~/.polipo-bak

# Invoke each polipo instance in a separate terminal. You will need to kill at least one of them *very* quickly.
env -i $HOME/polipo-install/bin/polipo logLevel=0xff proxyPort=8801
env -i $HOME/polipo-install/bin/polipo logLevel=0xff proxyPort=8802 parentProxy=127.0.0.1:8801

# In a third terminal, request a resource returning an HTTP 204
env -i http_proxy="http://127.0.0.1:8802/" curl http://stackoverflow.com/posts/1938932/ivc/621d

Curl exits immediately with the following output:
"""curl: (18) transfer closed with outstanding read data remaining"""

The second polipo(8802) produces no log output.

The first polipo(8801) repeats the following line for every request by the second polipo(8802):
"""Superseding object http://stackoverflow.com/posts/1938932/ivc/621d (204 -1 -1 (none) -> 204 -1 -1 (none))"""

Until the second polipo(8802) is killed, it will re-request the resource at an extremely high/abusive rate.
(12 times in the moment it took me to switch terminals and ctrl-c the second polipo.)

I do not have a capture of the traffic between the polipo instances, but I do have a tcpflow capture of the traffic between the first polipo (8801) and the Stackoverflow web server, as seen by my gateway, which I will attach momentarily.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Attachments (3)

rx.log (1.3 KB) - added by erik 9 years ago.
TCP Data sent from the Stackoverflow web server to the first Polipo instance
tx.log (2.3 KB) - added by erik 9 years ago.
TCP data sent from the first Polipo instance to the Stackoverflow web server
204_flood.log (6.7 KB) - added by qux 9 years ago.
A piece of tcpdump log with this issue

Download all attachments as: .zip

Change History (7)

Changed 9 years ago by erik

Attachment: rx.log added

TCP Data sent from the Stackoverflow web server to the first Polipo instance

Changed 9 years ago by erik

Attachment: tx.log added

TCP data sent from the first Polipo instance to the Stackoverflow web server

comment:1 Changed 9 years ago by qux

It seems like this happens not only with two instances of polipo. I've catch this with simpler case, browser -> local polipo -> origin server. While server responds 204, polipo sent ~130 requests per second even after exit from browser.
I have a 1.6mb tcpdump traffic snapshot of this issue and attached some piece of it.
This was seen with polipo-20080907. I added problematic address to forbidden list (it is ad counter) but can try to get this with more up-to-date version (now use git-20091229) if needed. Sorry for my English ;)

Changed 9 years ago by qux

Attachment: 204_flood.log added

A piece of tcpdump log with this issue

comment:2 Changed 9 years ago by loafier

I think I'm also able to duplicate this bug with a single instance of
Polipo (current git).

Looking into it.

comment:3 Changed 9 years ago by loafier

I think this should be fixed in commit eb91a8710f17870e4151f4889006933be8815dea

Closing this report for now.

comment:4 Changed 9 years ago by loafier

flyspray2trac: bug closed.

Note: See TracTickets for help on using tickets.