[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9349 [Flashproxy]: flashproxy facilitator: Allow clients to specify transports
#9349: flashproxy facilitator: Allow clients to specify transports
----------------------------+-------------------
Reporter: asn | Owner: dcf
Type: task | Status: new
Priority: normal | Milestone:
Component: Flashproxy | Version:
Resolution: | Keywords:
Actual Points: | Parent ID: #7167
Points: |
----------------------------+-------------------
Comment (by dcf):
Replying to [comment:14 asn]:
> Also pushed trivial flashproxy modifications in branch
`bug9349_proxy_side`.
{{{
+ params.push(["transports", "websocket"]);
}}}
I think I prefer `transport` here, not `transports`. If there are multiple
transports I want the query string to look like
{{{
transport=websocket&transport=webrtc
}}}
not
{{{
transports=websocket,webrtc
}}}
so that we don't have to invent our own format for list serialization, and
concomitant worries about escaping within URL escaping. To use such a
multiple-valued query string is easy, for example you can use Python's
[http://docs.python.org/2/library/cgi.html#cgi.FieldStorage.getlist
FieldStorage.getlist].
Likewise in facilitator transactions, I would like to see multiple
`TRANSPORT=` instead of one `TRANSPORTS=`. You will have to add a new
function in `fac.py` that is like `param_first` but it returns the whole
list of values.
{{{
+ transports = transport_list.join(",") # XXX wtf
try:
- command, params = transact(f, "GET", ("FROM",
format_addr(proxy_addr)))
+ command, params = transact(f, "GET", ("FROM",
format_addr(proxy_addr)), ("TRANSPORTS", transports))
}}}
In the facilitator, let's break backward compatibility and redefine the
`-r` option to be the name of the relay file to load.
Let's use a tuple to represent a transport chain internally--parse it with
`str.split("|")` as soon as it's read, and format it with `"|".join` only
just before output. Then `get_outermost_transport(chain)` is just
`chain[-1]`.
`options.relays` should be indexed not by complete transport chains, but
by transport chains excluding their last element. It should be possible
for an obfs3|websocket client to talk to an obfs3|tcp relay, if there is a
proxy that speaks both websocket and tcp. To be specific you should key by
the tuple `("obfs3",)` and not `("obfs3", "websocket")`.
I don't want to make a distinction between "new-style" and "old-style"
registrations. There is just one backward-compatible style. In your loop
over `fs.keys()`, notice a key that is exactly `client`, and treat it the
same as `client-websocket`.
I'm also hoping you will address the client comments from comment:10.
My plan for merging is to first do the proxy, because that's trivial and
doesn't require other changes, then merge the facilitator. We can then run
client registrations manually to test obfs-flash.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9349#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs