[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:              |
----------------------------+--------------------------

Comment (by infinity0):

 https://github.com/infinity0/flashproxy/compare/bug9349_server_endpoints...bug9349_server_urlparam

 Here is my code implementing the url-param syntax stuff. It builds on top
 of endpoints, since it takes advantage of some of the encapsulated data
 structures introduced in that branch.

 In the interests of a more consistent language for representing an
 (address,transport) pair, I tweaked dcf's suggested syntax above slightly:

 - client registration requests now look like "client-addr=_&client-
 transport=_"
 - facilitator responses now look like "client-addr=_&client-transport=_
 &relay-addr=_&relay-transport=_"
 - the transactional representation in fac.py now looks like "CLIENT
 addr=_&transport=_" and "RELAY addr=_&transport=_", reusing the qs
 parse/format code

 (I changed the facilitator response, since the reason we did the syntax in
 the first place was to get rid of dynamic keys in the param list. I added
 "-addr" so that the transactional representation is sane and constant.)

 Old client registrations of the form "client=_" still work, with implied
 transport=websocket.

 At the moment, simply specifying "client-addr=_" will raise an error, but
 I can have client-transport default to "websocket" if that is preferred.

 The addition of "-addr" does cause one slight untidiness - previously, the
 facilitator gave an empty "client=" value as a response to mean "no
 registrations available". This sort of fit into the old syntax, but is not
 really consistent with the new syntax. The old client= behaviour remains;
 we could change it to "look more" like the new syntax; but actually IMO we
 should pick an entirely different way to communicate this, since it is an
 exceptional status for the proxy.

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