[tor-bugs] #9349 [Flashproxy]: flashproxy facilitator: Allow clients to specify transports

[Tor Bug Tracker & Wiki]

#9349: flashproxy facilitator: Allow clients to specify transports
----------------------------+--------------------------
     Reporter:  asn         |      Owner:  dcf
         Type:  task        |     Status:  needs_review
     Priority:  normal      |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:  #7167
       Points:              |
----------------------------+--------------------------
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Replying to [comment:3 dcf]:
 > Let's consider the use case of a client that supports websocket,
 obfs3|websocket, and obfs3|tcp. It may send a registration message like,
 > {{{
 > client-websocket=1.2.3.4:1000&client-obfs3%7cwebsocket=1.2.3.4:2000
 &client-obfs3%7ctcp=1.2.3.4:3000
 > }}}

 Ximin and I had a discussion and came up with an idea for what I think is
 a better syntax. Instead of embedding information into parameter names,
 let's just separate multiple registrations by newlines:
 {{{
 client=1.2.3.4:1000&transport=websocket
 client=1.2.3.4:2000&transport=obfs3%7cwebsocket
 client=1.2.3.4:3000&transport=obfs3%7ctcp
 }}}
 The
 [https://gitweb.torproject.org/flashproxy.git/blob/cc0a4d12a18a458acbaaabe4db5f4f9eb6544d0b:/facilitator
 /facilitator-reg-daemon#l79 facilitator code currently in master] looks
 for a line starting with "client=", so we were already using a line-
 oriented format, even if not documented. We weren't documented to use URL
 query string syntax either, but I think it is a reasonable (and backward-
 compatible) choice.

 This is the last "feature" type change I think we should make. (I think it
 is worth making.) I attach a patch to do it.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9349#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online