It turns out that some panels like to set `"xmux": {"maxConnections": 0,
"maxConcurrency": 0}`, and of course that fails now. To make their job
easier, let's treat `0` the same as not setting the parameter.
Again, I don't like that xray's defaults are hardcoded all over the
place. I would have liked a different default value for Xmux in a future
version, but it actually can't be done in practice because everybody
just copypastes the defaults from the docs into their own sourcecode
(and sometimes changes them silently to their own idea of a good
default)
* Pin protobuf packages
It happened in the past that I ran with the wrong protobuf version
installed locally, and apparently there is even still some file wrong in
splithttp. Fix this issue once and for all.
* bump protobuf packages
* Revert "bump protobuf packages"
This reverts commit 7a3509346a.
* Revert "Revert "bump protobuf packages""
This reverts commit bb79707d15.
* fix deprecated grpc usage
* maxUploadSize -> scMaxEachPostBytes, default is 1MB on both sides (was 2MB on the server)
* minUploadIntervalMs -> scMinPostsIntervalMs, default is 30ms on the client (no server support for now)
* maxConcurrentUploads -> scMaxConcurrentPosts, default is 100 on both sides (was 200 on the server)
Testing was conducted only using explicit parameters, and using
testsuite. However, when the parameters are not explicitly set in JSON
config, it seems that `c.MaxUploadSize` will contain `RandRangeConfig {
From: 0, To: 0 }` instead of `nil`, which breaks upload entirely.
* maxUploadSize and maxConcurrentUploads can now be ranges on the client
* maxUploadSize is now enforced on the server
* the default of maxUploadSize is 2MB on the server, and 1MB on the client
* the default of maxConcurrentUploads is 200 on the server, and 100 on the client
* ranges on the server are treated as a single number. if server is configured as `"1-2"`, server will enforce `2`
* querystrings in `path` are now handled correctly
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
