this is achieved by a rework of the upgrade plugin, and the addition of
an h2 upgrade plugin. The idea is the following: if a response carries
an Upgrade header, and there's a handler for it, we should go for it.
The difference is:
* when the response is 101, this means that the negotiation must take
place before the actual response comes in;
* when the response is 200, upgrading means reconnecting to the channel,
and assume the new protocol for subsequent requests only.
connection
After the connection has been upgraded and session is kept open,
subsequent requests were still trying to upgrade it. This fixes it by
marking the connection as upgraded, and falling back to normal
behaviour when it is.
By setting the h2c protocol handler, the rest became much simpler.
Formatting the upgrade request is a matter for the sub-plugin.
Therefore, the specific h2c request upgrade headers are built-in there.
created a test server which removes the content-length. Taken extra
condition into account, that the close might manifest itself while
selecting on the socket; at that point we're out of the consumption
loop, so better not to deal with throwing :called
stream HTTP/2 framing errors were being yielded directly into the connection. This had
the issue of not closing the request, thereby causing an infinite loop
when closing the connection. This seemed to be the issue in CI.
another bug gets fixed after adding a test... the delay of sending the
request body when server doesn't support the Expect-100 continue dance
wasn't using the proper API. Adapted the handling of the state machine
to be more readable and compliant as well.
the packet wasn't being well formed in certain situations. Also, raised
restrictions for IPv6 addresses, as hton is implemented in more recent
rubies for them as well.
fails
While adding yet another test, an edge case was found where a proxy had
to be resolved, but when the resolving failed, the process wasn't
recovering from it.
When persistent and retries are loaded separately, the options won't be
just overwritten; instead, changes will be kept, and max_retries will be
the max value of what both plugins load (in case the user sets its own
option)
