[tor-bugs] #11183 [meek]: Make an HTTP requestor Firefox extension for meek-client

[Tor Bug Tracker & Wiki]

#11183: Make an HTTP requestor Firefox extension for meek-client
-------------------------+--------------------
     Reporter:  dcf      |      Owner:  dcf
         Type:  project  |     Status:  closed
     Priority:  normal   |  Milestone:
    Component:  meek     |    Version:
   Resolution:  fixed    |   Keywords:  meek
Actual Points:           |  Parent ID:  #10935
       Points:           |
-------------------------+--------------------

Comment (by gk):

 Replying to [comment:24 dcf]:
 > Replying to [comment:23 gk]:
 > > Replying to [comment:21 dcf]:
 > > > Replying to [comment:19 gk]:
 > > > > https://gitweb.torproject.org/user/dcf/tor-browser-
 bundle.git/blob/refs/heads/meek:/Bundle-Data/PTConfigs/meek-http-helper-
 user.js looks good. I am just wondering why you use the awkward dump() and
 do not hard-code a port on localhost to use...
 > > >
 > > > We talked about this on IRC today. The ephemeral port is to avoid
 local port conflicts. The dump call alerts the controller program, meek-
 client-torbrowser, what port to connect on, and also signals when the port
 is open and listening and safe to connect to.
 > > >
 > > > The dump call that writes the port number to stdout seems like an
 unusual use of the function, at least, so it's a candidate for replacement
 if we think of something better.
 > >
 > > I think a more natural way would be using nsIEnvironment for passing
 stuff around. At least it is much more common. Does something speak
 against this approach?
 >
 > Would that then require the pluggable transport to be a child process of
 the sub-Firefox, instead of a sibling as it is now?

 Uhm... I hadn't thought about that. Probably, yes. But that seems to be a
 lot of work (if it works at all) for little gain.

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