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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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):

 Replying to [comment:38 dcf]:
 > We should try to be backward compatible in this case. We won't be able
 to update all proxies instantly. As you say in comment:36, let's have
 `client` and `relay` in place of `client-addr` and `relay-addr`. `client-
 transport` and `relay-transport` are good names.
 >

 OK, I've pushed this to the branch above.

 > > - the transactional representation in fac.py now looks like "CLIENT
 addr=_&transport=_" and "RELAY addr=_&transport=_", reusing the qs
 parse/format code
 >
 > I really don't like this :( Here's what I see the facilitator returning
 to a `GET`:
 > {{{
 > OK CLIENT="client-transport=websocket&client=1.1.1.1%3A9000" RELAY
 ="relay-transport=websocket&relay=0.0.1.0%3A1" CHECK-BACK-IN="600"
 > }}}
 > I want the internal facilitator protocol to be very simple and not have
 embedded syntaxes.
 > Is there something wrong with the straightforward syntax?
 > {{{
 > OK CLIENT="1.1.1.1:9000" CLIENT-TRANSPORT="websocket" RELAY="0.0.1.0:1"
 RELAY-TRANSPORT="websocket" CHECK-BACK-IN="600"
 > }}}
 >

 We could do this and I actually even already wrote code that does exactly
 that. But it made the code shorter to reuse the qs-parsing stuff. Is it
 important for the transactional protocol to look nice? I think of it more
 as "black-box representation" rather than "embedded syntax".

 > > 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.
 >
 > `client=` is at least an unambiguous and backward-compatible way to
 indicate that there is no client registration. In the very early days we
 might have used a 404 to do it, but stopped because that caused a problem
 with Flash's HTTP retriever or XMLHttpRequest or both. I don't care too
 much as long as it works. If you can think of a better way, that's fine.
 >
 > Getting no client happens much more frequently than getting a client.

 OK, I've stuck with this for now because of the "-addr" removal. I might
 think about it a bit more if I get around to it.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9349#comment:39>
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