ReferenceError: age is not defined	snowflake.js:265:7
        BucketRateLimit.prototype.when	snowflake/proxy/build/snowflake.js:265:7
        ProxyPair.prototype.flush	snowflake/proxy/build/snowflake.js:558:63
        bind/<	snowflake/proxy/build/snowflake.js:10:56
        ProxyPair.prototype.onClientToRelayMessage	snowflake/proxy/build/snowflake.js:495:14
        bind/<	snowflake/proxy/build/snowflake.js:10:56

I got the warning:
	Expected declaration but found ‘/’.  Skipped to next declaration.

This was mainly a matter of more complete mocking.

You can nest a "describe" in a "describe":
  describe
    describe
      it

But you can't nest an "it" in an "it":
  describe
    it
      it

The nested "it"s were not getting run (or getting run, but their output
ignored, I'm not sure).

Before this change:
	41 specs, 0 failures
After:
	44 specs, 5 failures

The http2 package removed support for v1.8 in,
https://github.com/golang/net/commit/22700d5518f6200cd1355b9d417285458095e8da

and it says 1.9 isn't actively tested.

https://bugs.torproject.org/25600#comment:14

Snowflake in Tor Browser has been hanging after surfing for a while.
(Tor reports "no running bridges".) It only began happening after commit
12922a23, which caused snowflake-client not to log to a file by
default (leaving it to log to its default stderr). What seems to be
happening is that tor doesn't read from its PT clients' stderr, leaving
a buffer to fill up that eventually causes a hang.

https://bugs.torproject.org/22782

The semicolons made it look like the end of a declaration. I got these
errors in the Firefox console:

Expected declaration but found ‘1px’.  Skipped to next declaration. 1 embed.html:29:17
Expected declaration but found ‘-1px’.  Skipped to next declaration. 1 embed.html:30:17

https://snowflake-reg-test.appspot.com/ for the client (needs domain fronting)
https://snowflake-broker.bamsoftware.com/ for the proxies (no fronting)

Note that fronting to App Engine doesn't currently actually work because
of https://bugs.torproject.org/25804; this commit doesn't change that.

I'm intuiting that the purpose of linking to github was to show the
README, not to link to the source code per se, so I changed the link to
point to the wiki page rather than gitweb.torproject.org/....

https://bugs.torproject.org/23947#comment:15

The wiki page in turn links to the post.

It was already in the root README.md, but proxy/README.md is where I
always look for it.

Was missed in 3fe10f3e.

https://bugs.torproject.org/25344

5s matches DEFAULT_BROKER_POLL_INTERVAL in the JavaScript proxy.

This is set up so as long as the actual HTTPS requests take less time
than pollInterval, there will a steady one poll per pollInterval. If the
HTTPS requests take longer than that, there will be no delay between
polls.

Ignore SIGINT, honor TOR_PT_EXIT_ON_STDIN_CLOSE.

Cf. https://bugs.torproject.org/24875

This actually caused a nil pointer dereference panic when Accept
returned an error, because conn was nil.

From https://trac.torproject.org/projects/tor/ticket/21312#comment:33

Since 19b317e7

Follow up to ff8f3851

Similar to c834c76f

David Fifield authored 7 years ago and Arlo Breault committed 7 years ago

https://bugs.torproject.org/21312

Cf. corresponding change for proxy-go:
https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=ff8f3851082e8f7f8b4c8b99b161be35020aeb67

This is a port of commit e3f3054f8b74caa639a6d9be09702693af9a70e7 from
meek.

In the previous commit, we changed from separate Listen and Serve steps
to always calling ListenAndServe. However, we would really like to
immediately get feedback if any errors happen in the Listen step inside
the call, because it's much better for debugging if those errors get
reported to tor through SMETHOD-ERROR--rather than reporting success to
tor and actually logging an error only in the snowflake log. So we wait
100 ms for an error to occur before deciding that the Listen succeeded.

We don't need to apply this hack to the ACME HTTP-01 listener, because
it's a plaintext listener. Unlike in the TLS case, there isn't any
internal magic that the net library does that we have to rely on. We
just call net.ListenTCP and check for an error.

This is a port of commit cea86c937dc278ba6b2100c238b1d5206bbae2f0 from
meek. Its purpose is to remove the need to copy-paste parts of
net/http.Server.ListenAndServeTLS. Here is a copy of the commit message
from meek:

    The net/http package provides ListenAndServe and ListenAndServeTLS
    functions, but it doesn't provide a way to set up a listener without
    also entering an infinite serve loop. This matters for
    ListenAndServeTLS, which sets up a lot of magic behind the scenes for
    TLS and HTTP/2 support. Formerly, we had copy-pasted code from
    ListenAndServeTLS, but that code has only gotten more complicated in
    upstream net/http.

    The price we pay for this is that it's no longer possible for a server
    bindaddr to ask to listen on port 0 (i.e., a random ephemeral port).
    That's because we never get a change to find out what the listening
    address is, before entering the serve loop.

    What we gain is HTTP/2 support; formerly our copy-pasted code had the
    side effect of disabling HTTP/2, because it was copied from an older
    version and did things like
            config.NextProtos = []string{"http/1.1"}

    The new code calls http2.ConfigureServer first, but that's not what's
    providing HTTP/2 support. HTTP/2 support happens by default. The reason
    we call http2.ConfigureServer is because we need to set
    TLSConfig.GetCertificate, and http2.ConfigureServer is a convenient way
    to initialize TLSConfig in a way that is guaranteed to work with HTTP/2.

David Fifield authored 7 years ago and Arlo Breault committed 7 years ago

This way works when the base URL lacks a path, e.g.
"http://127.0.0.1:8080".
https://bugs.torproject.org/25472