0 causes this error:
	[info] addr_port_lookup(): Port "0" out of range
(Even though simply omitting the port number causes it to be assigned 0
internally.)

With higher precedence.

This is a replacement for X-Forwarded-For because App Engine doesn't
allow to set X-Forwarded-For, and doesn't set any equivalent header by
default.

Includes failing tests for X-Forwarded-For.

This is working towards #13171. Currently it's just getting
req.RemoteAddr as before, except that it's now setting the port number
to ":0" in all cases.

These used to be set using the web interface. Now you have to set them
in app.yaml. For example,
https://cloud.google.com/appengine/docs/adminconsole/performancesettings#Setting_the_Number_of_Idle_Instances
now redirects to
https://cloud.google.com/appengine/docs/developers-console/#module-settings
which says:
	Note: Many performance settings for modules are included in the
	module's configuration file (Java | Python | Go | PHP). These
	settings are made at deployment time and cannot be changed from
	the Developers Console.
So we've been running without the settings I set manually before for who
knows how long. Previously I had set:
  max_idle_instances: 2
  min_pending_latency: 1000ms
Now I set it to:
  max_idle_instances: 2
  min_pending_latency: 1000ms

The new URL for the documentation of these parameters is here:
https://cloud.google.com/appengine/docs/go/modules/#Go_Configuration

https://lists.torproject.org/pipermail/tor-talk/2015-July/038496.html
https://trac.torproject.org/projects/tor/ticket/16634

https://gitweb.torproject.org/pluggable-transports/goptlib.git/commit/?id=65fc8d72eccd82237562744ddc85760d426561d8

https://trac.torproject.org/projects/tor/ticket/14135
https://gitweb.torproject.org/pluggable-transports/goptlib.git/commit/?id=50b39b746c6ff34bf31977b658848d876ee84fbf

These were the cause of the profile error that you saw when restarting
Tor Browser after an update.
https://trac.torproject.org/projects/tor/ticket/13247#comment:17

Ensure that update-related browser preferences are written to
disk by flushing them during startup.

It started being closed in 1fa2da7c,
which added compliance with the TOR_PT_EXIT_ON_STDIN_CLOSE environment
variable. Closing stdin of the subprocess doesn't make sense, because
the purpose of terminateprocess-buffer is to keep the chile stdin open
after its own stdin has closed.

This fixes a regression in Tor Browser 4.5 on Windows 7:
https://trac.torproject.org/projects/tor/ticket/15872#comment:5
However, the same code, even when it closes stdin, works on Windows 8,
and I don't know why.

This improves performance quite a lot--previously we were doing a
complete TCP and TLS handshake to meek-server for every single request,
which, apart from increasing latency, also caused a lot of CPU usage on
meek-server. it was up above 80% when I checked it.

Now we reuse connections until they error out, making a new connection
if all others are currently busy.

It was reading unlimitedly in this case.

There's now an official way for tor to request this behavior.

Since #15435, we can treat terminateprocess-buffer as a compatibility
shim that adds support for TOR_PT_EXIT_ON_STDIN_CLOSE to versions of tor
that don't have it.

Stripping Host made it not work to use a url= without a front=. When you
omit front=, it's supposed to take the Host from the url= argument. This
is when you connect directly to the bridge, like
	bridge meek 0.0.2.0:3 url=https://meek.bamsoftware.com/

No reason for it to be a member function.

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/NsIStreamListener#onDataAvailable%28%29
says "Your implementation of this method must read exactly aCount bytes
of data before returning."

It's already downloaded, so it doesn't cost much to read it out of the
buffer. Without this, I got "http channel Listener OnDataAvailable
contract violation" in the console. (I had to purposely induce an
overlong download to get it to happen.)

This enables us to send a meaningful {"error": "..."} blob back to the
requestor.

Use exceptions instead of dumping to console.

All our deployed backends are using HTTPS in forwarding. Might as well
make it the default for DIY deployers. I seem to remember that we once
had trouble on some platform (maybe some PHP host) because the installed
PHP library didn't have SSL support, but whatever.

let is block scope, which is what I always want.

05f244a5 removed logging of a couple of
errors that could contain client IP addresses. It turns out that these
errors were of type *net.OpError, the address field of which you can
overwrite from the outside.