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.
As with commit fcc274ac68 for the broker,
we need to start using the HTTP-01 challenge type in the Snowflake
websocket server transport plugin.
https://bugs.torproject.org/25346
It also expects to be called with a non-empty string, which isn't
the case with this Split which always envokes the loop at least
once. If -ice was omitted, an error was logged.
Current versions of tor accept USERADDR with or without a port number,
but future versions may become more strict and require the port number.
https://bugs.torproject.org/23080
Rather than having it happen as a side effect of flag parsing.
Having it happen as a side effect of flag parsing caused log messages
related to handling the option (e.g. "IceServerList:") to always go to
stderr, despite the presence of a -log option. This is because the
requested log file had not been opened yet.
This prohibits some nonsense like "./proxy-go -capacity -550", which
otherwise results in a panic like:
INFO: configuration.go:174: Created Configuration at &{[{[stun:stun.l.google.com:19302] }] All Balanced }
panic: makechan: size out of range
This is a hedge against any bugs that may cause the badge to hang when
left running for a long time, and it also means that badges will
effectively check for updated code once a day.
