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

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

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

 Replying to [comment:26 gk]:
 > Replying to [comment:22 dcf]:
 > > Replying to [comment:20 gk]:
 > > > I have to think a bit about your usage of nsISocketTransport and
 whether you are affected by the things we ran into in #9531. See the
 comments there (e.g. regarding OPEN_BLOCKING|OPEN_UNBUFFERED)
 > >
 > > Okay. I don't know what to make of that.
 >
 > Sorry for the delay. Here comes the second part of the code review for
 https://gitweb.torproject.org/pluggable-
 transports/meek.git/blob/HEAD:/firefox/components/main.js. Basically, it
 looks good to me. Nice work! One nit is the trailing comma after
 > {{{
 > status: context.responseStatus
 > }}}
 > but that may be deliberate again (what is the rationale for this, btw?).

 Thank you for the review.

 The trailing comma is so that there's only a single line in the diff when
 you add or remove something from the literal. The trailing comma is part
 of the [http://www.ecma-international.org/ecma-262/5.1/#sec-11.1.4
 ArrayLiteral] and [http://www.ecma-
 international.org/ecma-262/5.1/#sec-11.1.5 ObjectLiteral] syntax. It's a
 part of most other languages too: the K&R C book says "A list may end with
 a comma, a nicety for neat formatting." As I recall, there's a problem
 with trailing commas in Internet Explorer, but this file is for Firefox
 only so I don't worry about it.

 > Then I was wondering about the length limit especially that of the
 response. What is the reasoning behind it? Doesn't that prohibit certain
 use cases like retrieving PDF files larger than 1000000 Bytes?

 That's a good question. The limit is per-request, and it's only a failsafe
 in case limits are not enforced in other parts of the code. The meek-
 client and meek-server programs actually use a smaller limit of 65536
 bytes per request, but I tried to design the programs so they don't trust
 one another. If a malicious meek-client or meek-server sends an endless
 stream of data, the browser extension should fail fast with an error
 rather than buffer forever. Similarly meek-client tries to protect itself
 from a malicious browser extension (see maxHelperResponseLength in
 helper.go).

 A Tor stream is multiplexed across multiple requests and responses. The
 meek-client and meek-server programs reconstruct the HTTP into continuous
 TCP sessions at both ends. So it doesn't matter too much how big each
 individual payload is (though there is a tradeoff between bandwidth and
 latency). I've downloaded files of hundreds of megabytes.

 > And, finally, there is no option to get OPEN_BLOCKING and
 OPEN_UNBUFFERED (see https://mxr.mozilla.org/mozilla-
 esr24/source/netwerk/base/src/nsSocketTransport2.cpp#1755) and the Necko
 folks won't implement that.

 So if I understand this correctly, `OPEN_BLOCKING|OPEN_UNBUFFERED` is the
 same as just `OPEN_BLOCKING`? Should I change it to just `OPEN_BLOCKING`?

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