- tor-commits - lists.torproject.org

[flashproxy/master] Add SOCKS4 reference URL.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 55c7329b70268eaf0f0fdb6dcd471740ac8cb195 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 06:57:36 2012 -0700 Add SOCKS4 reference URL. --- connector.py | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/connector.py b/connector.py index 353d6b5..333997a 100755 --- a/connector.py +++ b/connector.py @@ -553,6 +553,8 @@ def grab_string(s, pos): i += 1 return pos, None +# http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol +# https://en.wikipedia.org/wiki/SOCKS#SOCKS4a def parse_socks_request(data): """Parse the 8-byte SOCKS header at the beginning of data. Returns a (dest, port) tuple. Raises ValueError on error."""

1 0

[flashproxy/master] Shorten parse_socks_request log messages.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 49f8f59838890dc565d01a1956953d6e1359af51 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 07:09:39 2012 -0700 Shorten parse_socks_request log messages. --- connector.py | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/connector.py b/connector.py index 333997a..7a180df 100755 --- a/connector.py +++ b/connector.py @@ -563,16 +563,16 @@ def parse_socks_request(data): except struct.error: raise ValueError("Couldn't unpack SOCKS4 header") if ver != 4: - raise ValueError("SOCKS header has wrong version (%d)" % ver) + raise ValueError("Wrong SOCKS version (%d)" % ver) if cmd != 1: - raise ValueError("SOCKS header had wrong command (%d)" % cmd) + raise ValueError("Wrong SOCKS command (%d)" % cmd) pos, userid = grab_string(data, 8) if userid is None: - raise ValueError("Couldn't read userid from SOCKS header") + raise ValueError("Couldn't read userid") if o1 == 0 and o2 == 0 and o3 == 0 and o4 != 0: pos, dest = grab_string(data, pos) if dest is None: - raise ValueError("Couldn't read destination from SOCKS4a header") + raise ValueError("Couldn't read destination") else: dest = "%d.%d.%d.%d" % (o1, o2, o3, o4) return dest, dport @@ -587,7 +587,7 @@ def handle_socks_request(fd): try: dest_addr = parse_socks_request(data) except ValueError, e: - log(u"Error parsing SOCKS header: %s." % str(e)) + log(u"Error parsing SOCKS request: %s." % str(e)) # Error reply. fd.sendall(struct.pack(">BBHBBBB", 0, 91, 0, 0, 0, 0, 0)) return False

1 0

[flashproxy/master] Scrub IP addresses in connector.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit ec5fadb60d4c6a702dcc25d4e0cb40c79ea97f25 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 07:26:10 2012 -0700 Scrub IP addresses in connector. --- connector.py | 43 +++++++++++++++++++++++++++++++++++-------- 1 files changed, 35 insertions(+), 8 deletions(-) diff --git a/connector.py b/connector.py index 7a180df..8afd0c0 100755 --- a/connector.py +++ b/connector.py @@ -46,6 +46,7 @@ class options(object): daemonize = False register = False pid_filename = None + safe_logging = True # We accept up to this many bytes from a socket not yet matched with a partner # before disconnecting it. @@ -72,13 +73,21 @@ facilitator is used; if omitted, it uses a public default. -h, --help show this help. -l, --log FILENAME write log to FILENAME (default stdout). --pidfile FILENAME write PID to FILENAME after daemonizing. - -r, --register register with the facilitator.\ + -r, --register register with the facilitator. + --unsafe-logging don't scrub IP addresses from logs.\ """ % { "progname": sys.argv[0], "local": format_addr((DEFAULT_LOCAL_ADDRESS, DEFAULT_LOCAL_PORT)), "remote": format_addr((DEFAULT_REMOTE_ADDRESS, DEFAULT_REMOTE_PORT)), } +def safe_str(s): + """Return s if options.safe_logging is true, and "[scrubbed]" otherwise.""" + if options.safe_logging: + return "[scrubbed]" + else: + return s + def log(msg): print >> options.log_file, (u"%s %s" % (time.strftime(LOG_DATE_FORMAT), msg)).encode("UTF-8") options.log_file.flush() @@ -133,6 +142,22 @@ def format_addr(addr): else: return u"%s:%d" % (host, port) +def safe_format_addr(addr): + return safe_str(format_addr(addr)) + host, port = addr + if not host: + return u":%d" % port + # Numeric IPv6 address? + try: + addrs = socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM, socket.IPPROTO_TCP, socket.AI_NUMERICHOST) + af = addrs[0][0] + except socket.gaierror, e: + af = 0 + if af == socket.AF_INET6: + return u"[%s]:%d" % (host, port) + else: + return u"%s:%d" % (host, port) + def apply_mask_numpy(payload, mask_key): @@ -419,7 +444,7 @@ def listen_socket(addr): def format_peername(s): try: - return format_addr(s.getpeername()) + return safe_format_addr(s.getpeername()) except socket.error, e: return "<unconnected>" @@ -591,7 +616,7 @@ def handle_socks_request(fd): # Error reply. fd.sendall(struct.pack(">BBHBBBB", 0, 91, 0, 0, 0, 0, 0)) return False - log(u"Got SOCKS request for %s." % format_addr(dest_addr)) + log(u"Got SOCKS request for %s." % safe_format_addr(dest_addr)) fd.sendall(struct.pack(">BBHBBBB", 0, 90, dest_addr[1], 127, 0, 0, 1)) # Note we throw away the requested address and port. return True @@ -770,15 +795,15 @@ def main(): for fd in rset: if fd == remote_s: remote_c, addr = fd.accept() - log(u"Remote connection from %s." % format_addr(addr)) + log(u"Remote connection from %s." % safe_format_addr(addr)) websocket_pending.append(TimeoutSocket(remote_c)) elif fd == local_s: local_c, addr = fd.accept() - log(u"Local connection from %s." % format_addr(addr)) + log(u"Local connection from %s." % safe_format_addr(addr)) socks_pending.append(local_c) register() elif fd in websocket_pending: - log(u"Data from WebSocket-pending %s." % format_addr(addr)) + log(u"Data from WebSocket-pending %s." % safe_format_addr(addr)) protocols = handle_websocket_request(fd) if protocols is not None: wrapped = RemoteSocket(fd, protocols) @@ -789,7 +814,7 @@ def main(): websocket_pending.remove(fd) report_pending() elif fd in socks_pending: - log(u"SOCKS request from %s." % format_addr(addr)) + log(u"SOCKS request from %s." % safe_format_addr(addr)) if handle_socks_request(fd): wrapped = LocalSocket(fd) locals.append(wrapped) @@ -833,7 +858,7 @@ def main(): report_pending() if __name__ == "__main__": - opts, args = getopt.gnu_getopt(sys.argv[1:], "f:hl:r", ["daemon", "facilitator=", "help", "log=", "pidfile=", "register"]) + opts, args = getopt.gnu_getopt(sys.argv[1:], "f:hl:r", ["daemon", "facilitator=", "help", "log=", "pidfile=", "register", "unsafe-logging"]) for o, a in opts: if o == "--daemon": options.daemonize = True @@ -848,6 +873,8 @@ if __name__ == "__main__": options.pid_filename = a elif o == "-r" or o == "--register": options.register = True + elif o == "--unsafe-logging": + options.safe_logging = False if len(args) == 0: options.local_addr = (DEFAULT_LOCAL_ADDRESS, DEFAULT_LOCAL_PORT)

1 0

[flashproxy/master] Move design.txt to doc.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 210d5b2e98e3b6deff480310cd7e424c962fd928 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 06:09:13 2012 -0700 Move design.txt to doc. --- design.txt | 157 -------------------------------------------------------- doc/design.txt | 157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 157 insertions(+), 157 deletions(-) diff --git a/design.txt b/design.txt deleted file mode 100644 index ecee83c..0000000 --- a/design.txt +++ /dev/null @@ -1,157 +0,0 @@ -Design of flash proxies - -0. Problem statement - - Provide access to the Tor network for users behind a restrictive - firewall that blocks direct access to all Tor relays and bridges. - -1. Overview and background - - We assume the existence of an adversary powerful enough to enumerate - and block all public and non-public (bridge) relays. For users facing - such an adversary, we assume there exists a subset of reachable hosts - that themselves can reach the Tor network. We call this subset the - unrestricted Internet. - - A browser-based proxy (flash proxy), running in a web page in the - unrestricted Internet, proxies connections between the restricted - Internet and the Tor network. These proxies are expected to be - temporary and short-lived, but their number will be great enough that - they can't all be blocked effectively. - - The implementation of a browser-based proxy using Adobe Flash or other - networking technologies is complicated by restrictions that prevent it - being a straightforward proxy. Chief among these is the lack of - listening sockets. Flash and, for example, WebSockets, can only - initiate outgoing connections, not receive incoming ones. The flash - proxy can only connect to external hosts by connecting directly to - them. The other significant restriction is that the proxy cannot - connect to just any destination. A third, but less important, - restriction is that browser-based networking does not provide - low-level socket access such as control of source address. - -2. Components - - Conceptually, each flash proxy is nothing more than a simple proxy, - which accepts connections from a client and forwards data to a server. - But because of the limited networking facilities available to an - in-browser application, several other pieces are needed. - - 1. Tor client: Is just ordinary Tor with a special configuration to - allow it to connect through a flash proxy. It advertises its need - for a connection the the facilitator, and communicates with the - flash proxy through the connector. - 2. Connector: Runs on the same computer as the Tor client. It opens - one socket to the Internet and another to localhost. It waits for a - connection on both sockets, then starts proxying data between them. - The connector speaks SOCKS on the localhost side so that Tor can - connect to it using the Socks4Proxy configuration option. On - startup, the connector informs the facilitator that it is waiting - for a connection. - 3. Flash proxy: Runs in someone's browser, in an uncensored region of - the Internet. The flash proxy first connects to the facilitator to - get a client registration. It then makes two outgoing connections, - one to a Tor relay and one to a waiting Tor client, and starts - proxying data between them. - 4. Facilitator: Keeps track of client registrations and hands them out - to clients. It is capable of receiving client registrations in a - variety of ways. It sends registrations to flash proxies over HTTP. - The facilitator is responsible for matching clients to proxies in a - reasonable manner. - 5. Tor relay: An ordinary Tor relay. - -4. Sample session - - 1. The restricted Tor user starts the connector program. - 2. The restricted user starts Tor, which makes a SOCKS connection to - the connector. - 3. The connector notifies the facilitator that it needs a connection. - 4. An unrestricted user opens the web page containing the flash proxy. - 5. The flash proxy connects to the facilitator and asks for a client. - 6. The facilitator sends one of its client registrations to the proxy. - 7. The flash proxy connects to a Tor relay and to the waiting client - connector. - 8. The connector receives the flash proxy's connection and begins - relaying data between it and the Tor relay. - - Later, the flash proxy may go offline. Assuming that another flash - proxy is available, it will receive the same client's address from the - facilitator, and the local Tor client will reconnect to the client - through it. - -5. Behavior of the Tor client - - The Tor client must be configured to make its connections through a - local proxy (the connector). This configuration is sufficient: - UseBridges 1 - Bridge 127.0.0.1:9001 - Socks4Proxy 127.0.0.1:9001 - The address given for the "Bridge" option is actually irrelevant. The - connector will ignore it and connect (through the flash proxy) to a - Tor relay. The Tor client does not have control of its first hop. - -6. Behavior of the connector - - The connector serves two purposes: It sends a registration message to - the facilitator and it carries data between a flash proxy and the - local Tor client. - - On startup, the connector sends a registration message to the - facilitator, informing the facilitator that it is waiting for a - connection. The facilitator will later hand this registration to a - flash proxy. The registration message is an HTTP POST request of the - form: - - POST / HTTP/1.0 - - client=[<address>]:<port> - - The facilitator sends a 200 reply if the registration was successful - and an error status otherwise. If the connector omits the [<address>] - part, the facilitator will automatically fill it in based on the HTTP - client address, which means the connector doesn't have to know its - external address. - - The connector solves the impedance mismatch between the Tor client and - the flash proxy, both of which want to make outgoing connections to - the other. The connector sits in between, listens for connections from - both ends, and matches them together. The remote socket listens on - port 9000 and the local on port 9001. - - On the local side, it acts as a SOCKS proxy (albeit one that always - goes to the same destination). - -7. Behavior of the flash proxy - - The flash proxy polls the facilitator for client registrations. When - it receives a registration, it opens one connection to the given Tor - relay, one to the given client, and begin proxying data between them. - - The proxy asks the facilitator for a registration with an HTTP GET - request: - - GET / HTTP/1.0 - - - The response code is 200 and the body looks like this: - - client=[<address>:<port>]&relay=<address>:<port> - - If the value for the client parameter is empty, it means that there are no - client registrations for this proxy. - - The flash proxy may serve more than one relay–client pair at once. - -8. Behavior of the facilitator - - The faciliator is a HTTP server that handles client POST registrations - and proxy GET requests according to the formats given above. The - facilitator listens on port 9002. - - In the current implementation, the facilitator forgets a client - registration after giving it to a flash proxy. The client must - re-register if it wants another connection later. - -9. Behavior of the Tor relay. - - The Tor relay requires no special configuration. diff --git a/doc/design.txt b/doc/design.txt new file mode 100644 index 0000000..ecee83c --- /dev/null +++ b/doc/design.txt @@ -0,0 +1,157 @@ +Design of flash proxies + +0. Problem statement + + Provide access to the Tor network for users behind a restrictive + firewall that blocks direct access to all Tor relays and bridges. + +1. Overview and background + + We assume the existence of an adversary powerful enough to enumerate + and block all public and non-public (bridge) relays. For users facing + such an adversary, we assume there exists a subset of reachable hosts + that themselves can reach the Tor network. We call this subset the + unrestricted Internet. + + A browser-based proxy (flash proxy), running in a web page in the + unrestricted Internet, proxies connections between the restricted + Internet and the Tor network. These proxies are expected to be + temporary and short-lived, but their number will be great enough that + they can't all be blocked effectively. + + The implementation of a browser-based proxy using Adobe Flash or other + networking technologies is complicated by restrictions that prevent it + being a straightforward proxy. Chief among these is the lack of + listening sockets. Flash and, for example, WebSockets, can only + initiate outgoing connections, not receive incoming ones. The flash + proxy can only connect to external hosts by connecting directly to + them. The other significant restriction is that the proxy cannot + connect to just any destination. A third, but less important, + restriction is that browser-based networking does not provide + low-level socket access such as control of source address. + +2. Components + + Conceptually, each flash proxy is nothing more than a simple proxy, + which accepts connections from a client and forwards data to a server. + But because of the limited networking facilities available to an + in-browser application, several other pieces are needed. + + 1. Tor client: Is just ordinary Tor with a special configuration to + allow it to connect through a flash proxy. It advertises its need + for a connection the the facilitator, and communicates with the + flash proxy through the connector. + 2. Connector: Runs on the same computer as the Tor client. It opens + one socket to the Internet and another to localhost. It waits for a + connection on both sockets, then starts proxying data between them. + The connector speaks SOCKS on the localhost side so that Tor can + connect to it using the Socks4Proxy configuration option. On + startup, the connector informs the facilitator that it is waiting + for a connection. + 3. Flash proxy: Runs in someone's browser, in an uncensored region of + the Internet. The flash proxy first connects to the facilitator to + get a client registration. It then makes two outgoing connections, + one to a Tor relay and one to a waiting Tor client, and starts + proxying data between them. + 4. Facilitator: Keeps track of client registrations and hands them out + to clients. It is capable of receiving client registrations in a + variety of ways. It sends registrations to flash proxies over HTTP. + The facilitator is responsible for matching clients to proxies in a + reasonable manner. + 5. Tor relay: An ordinary Tor relay. + +4. Sample session + + 1. The restricted Tor user starts the connector program. + 2. The restricted user starts Tor, which makes a SOCKS connection to + the connector. + 3. The connector notifies the facilitator that it needs a connection. + 4. An unrestricted user opens the web page containing the flash proxy. + 5. The flash proxy connects to the facilitator and asks for a client. + 6. The facilitator sends one of its client registrations to the proxy. + 7. The flash proxy connects to a Tor relay and to the waiting client + connector. + 8. The connector receives the flash proxy's connection and begins + relaying data between it and the Tor relay. + + Later, the flash proxy may go offline. Assuming that another flash + proxy is available, it will receive the same client's address from the + facilitator, and the local Tor client will reconnect to the client + through it. + +5. Behavior of the Tor client + + The Tor client must be configured to make its connections through a + local proxy (the connector). This configuration is sufficient: + UseBridges 1 + Bridge 127.0.0.1:9001 + Socks4Proxy 127.0.0.1:9001 + The address given for the "Bridge" option is actually irrelevant. The + connector will ignore it and connect (through the flash proxy) to a + Tor relay. The Tor client does not have control of its first hop. + +6. Behavior of the connector + + The connector serves two purposes: It sends a registration message to + the facilitator and it carries data between a flash proxy and the + local Tor client. + + On startup, the connector sends a registration message to the + facilitator, informing the facilitator that it is waiting for a + connection. The facilitator will later hand this registration to a + flash proxy. The registration message is an HTTP POST request of the + form: + + POST / HTTP/1.0 + + client=[<address>]:<port> + + The facilitator sends a 200 reply if the registration was successful + and an error status otherwise. If the connector omits the [<address>] + part, the facilitator will automatically fill it in based on the HTTP + client address, which means the connector doesn't have to know its + external address. + + The connector solves the impedance mismatch between the Tor client and + the flash proxy, both of which want to make outgoing connections to + the other. The connector sits in between, listens for connections from + both ends, and matches them together. The remote socket listens on + port 9000 and the local on port 9001. + + On the local side, it acts as a SOCKS proxy (albeit one that always + goes to the same destination). + +7. Behavior of the flash proxy + + The flash proxy polls the facilitator for client registrations. When + it receives a registration, it opens one connection to the given Tor + relay, one to the given client, and begin proxying data between them. + + The proxy asks the facilitator for a registration with an HTTP GET + request: + + GET / HTTP/1.0 + + + The response code is 200 and the body looks like this: + + client=[<address>:<port>]&relay=<address>:<port> + + If the value for the client parameter is empty, it means that there are no + client registrations for this proxy. + + The flash proxy may serve more than one relay–client pair at once. + +8. Behavior of the facilitator + + The faciliator is a HTTP server that handles client POST registrations + and proxy GET requests according to the formats given above. The + facilitator listens on port 9002. + + In the current implementation, the facilitator forgets a client + registration after giving it to a flash proxy. The client must + re-register if it wants another connection later. + +9. Behavior of the Tor relay. + + The Tor relay requires no special configuration.

1 0

[flashproxy/master] Remove swfcatsim idea.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 400238deefc640fe29aa8e64487b2aab51b034fd Author: David Fifield <david(a)bamsoftware.com> Date: Sun Jun 24 21:36:03 2012 -0700 Remove swfcatsim idea. --- notes.txt | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/notes.txt b/notes.txt index 61babdc..b521bef 100644 --- a/notes.txt +++ b/notes.txt @@ -9,13 +9,6 @@ reconnecting through a new proxy. Tor remembers the host fingerprint from the first connection (to the bridge it thinks is at 127.0.0.1) and balks at connecting to the same address with a different fingerprint. -Could be useful to have a swfcatsim.py program. This would simulate -a swfcat instance (perhaps without the crossdomain stuff), providing -a bridge with a lifetime randomly chosen from some distribution. (For -example: "simulate proxies connecting according to this Poisson -distribution and staying connected according to this exponential -distribution.") - == How to use with an SSH proxy Start swfcat, giving it a relay parameter pointing to your SSH server.

1 0

[flashproxy/master] Remove understanding of RTMFP regs from facilitator.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 4fe3bf784716eb90b2f240cd686dce6849c5d0e3 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 04:10:48 2012 -0700 Remove understanding of RTMFP regs from facilitator. --- facilitator.py | 19 ------------------- 1 files changed, 0 insertions(+), 19 deletions(-) diff --git a/facilitator.py b/facilitator.py index 3e7ca09..83de49b 100755 --- a/facilitator.py +++ b/facilitator.py @@ -129,22 +129,6 @@ class TCPReg(object): else: return False -class RTMFPReg(object): - def __init__(self, id): - self.id = id - - def __unicode__(self): - return u"%s" % self.id - - def __str__(self): - return unicode(self).encode("UTF-8") - - def __cmp__(self, other): - if isinstance(other, RTMFPReg): - return cmp(self.id, other.id) - else: - return False - class Reg(object): @staticmethod def parse(spec, defhost = None, defport = None): @@ -163,9 +147,6 @@ class Reg(object): host, port = socket.getnameinfo(addrs[0][4], socket.NI_NUMERICHOST | socket.NI_NUMERICSERV) return TCPReg(host, int(port)) - if re.match(ur'^[0-9A-Fa-f]{64}$', spec): - return RTMFPReg(spec) - raise ValueError("Bad spec format: %s" % repr(spec)) class RegSet(object):

1 0

[flashproxy/master] Remove Flash /crossdomain.xml from facilitator.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 540fda8e1f1f07567accf1972b7cfb39323f2f03 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 04:12:34 2012 -0700 Remove Flash /crossdomain.xml from facilitator. --- facilitator.py | 17 ----------------- 1 files changed, 0 insertions(+), 17 deletions(-) diff --git a/facilitator.py b/facilitator.py index 83de49b..5ab7449 100755 --- a/facilitator.py +++ b/facilitator.py @@ -190,10 +190,6 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): path = urlparse.urlsplit(self.path)[2] - if path == u"/crossdomain.xml": - self.send_crossdomain() - return - reg = REGS.fetch() if reg: log(u"proxy %s gets %s, relay %s (now %d)" % @@ -235,19 +231,6 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): self.send_response(200) self.end_headers() - def send_crossdomain(self): - crossdomain = """\ -<cross-domain-policy> -<allow-access-from domain="*"/> -</cross-domain-policy> -""" - self.send_response(200) - # Content-Type must be one of a few whitelisted types. - # http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html#_Co… - self.send_header("Content-Type", "application/xml") - self.end_headers() - self.wfile.write(crossdomain) - def send_error(self, code, message = None): self.send_response(code) self.end_headers()

1 0

[flashproxy/master] Factor out client reg sending.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit f99c686d4a6ab7296a5023338944b1b88d8a48bc Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 05:10:32 2012 -0700 Factor out client reg sending. --- facilitator.py | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/facilitator.py b/facilitator.py index 040d189..be3436c 100755 --- a/facilitator.py +++ b/facilitator.py @@ -201,10 +201,9 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): if reg: log(u"proxy %s gets %s, relay %s (now %d)" % (safe_str(proxy_addr_s), safe_str(unicode(reg)), options.relay_spec, len(REGS))) - self.send_client(reg) else: log(u"proxy %s gets none" % safe_str(proxy_addr_s)) - self.send_client(None) + self.send_client(reg) def do_POST(self): client_addr_s = format_addr(self.client_address)

1 0

[flashproxy/master] Remove the "proxy connects" log message.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 7d047b2e4ad56b1c652c16a1ef76739ee021addb Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 05:10:17 2012 -0700 Remove the "proxy connects" log message. --- facilitator.py | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/facilitator.py b/facilitator.py index ed06301..040d189 100755 --- a/facilitator.py +++ b/facilitator.py @@ -195,8 +195,6 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): def do_GET(self): proxy_addr_s = format_addr(self.client_address) - log(u"proxy %s connects" % safe_str(proxy_addr_s)) - path = urlparse.urlsplit(self.path)[2] reg = REGS.fetch()

1 0

[flashproxy/master] Don't log anything for a broken pipe.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 67b1ad61f81ff75e9bc5ee35e73382e4129f7469 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 05:14:45 2012 -0700 Don't log anything for a broken pipe. --- facilitator.py | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/facilitator.py b/facilitator.py index be3436c..0a6a018 100755 --- a/facilitator.py +++ b/facilitator.py @@ -292,7 +292,6 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): raise if err_num != errno.EPIPE: raise - log(u"%s broken pipe" % safe_str(format_addr(self.client_address))) return ret handle = catch_epipe(BaseHTTPServer.BaseHTTPRequestHandler.handle) finish = catch_epipe(BaseHTTPServer.BaseHTTPRequestHandler.finish)

1 0