When Close and Push are called concurrently, it may happen that Push attempts to write to an already-closed channel, and trigger a panic.
From a user perspective, it results in logs like this:
http: panic serving 172.19.0.6:50476: send on closed channel
It's probably triggered when download is closed at the same time an upload packet is submitted.
These panics don't crash the server and the inbound is still usable.
Fix#3566
Also update testsuite so that all tests read and write some data. Opening a connection is not enough to trigger connection errors, because the connection is so lazy.
* Add H2C support to server
* update comment
* Make http1.1 ALPN work on SplitHTTP client
Users that encounter protocol version issues will likely try to set the
ALPN explicitly. In that case we should simply grant their wish, because
the intent is obvious.
* drain buffer correctly in httpupgrade
it seems the recently added httupgrade testsuite is causing timeouts on master
i have no evidence this is the real issue, but it feels to me that the
server could accidentally over-read, and then the encapsulated
connection will block forever trying to read data
let's test it in CI a couple of times, i don't have a way to reproduce
the issue
* correctly drain buffer, again
* preserve exact header casing when using httpupgrade
* fix capitalization of websocket
* oops, we dont need net/url either
* restore old codepath when there are no headers
mmmray