when closed, connections are now placed in a place called eden_connections; whenever a connection is matched for, after checking the live connections and finding none, a match is looked in eden connections; the match is accepted **if** the IP is considered fresh (the input is validated in the cache, or input was an ip or in /etc/hosts, or it's an external socket) and, if a TLS connection, the stored TLS session did not expire; if these conditions do not match, the connection is dropped from the eden and a new connection will started instead; this will therefore allow reusing ruby objects, reusing TLS sessions, and still respect the DNs cache
when connections get reset due to max number of requests being reached,
the same TLS session is going to be reused, as long as it's valid.
This change is ported from the same feature in net-http, including [the
tls 1.3
improvements](ddf5c52b5f)
The reference for a request verb is now the string which is used
everywhere else, instead of the symbol corresponding to it. This was an
artifact from the import from httprb, and there is no advantage in it,
since these strings are frozen in most use cases, and the
transformations from symbol to strings being performed everywhere are
prooof that keeping the atom isn't really bringing any benefit.
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.
server not being processed
While introducing yet another test to catch frame processing errors, in
this case with the SETTINGS_TIMEOUT error, another loop was found. It
was caused by two reasons:
* connection was signaling it was "closing" on such an error, which is
not really true (server already closed the stream, so no need to
close it again); it should be marked as closed instead.
* write buffer was still full (with the handshake in this case), so the
connection was still trying to write;
While adding the test, the code to recover from an exhausted HTTP/1.1
connection proved not to be reliable, as it wasn't taking inflight
requests nor update-once keep-alive max requests counters into
account.
This has been fixed by implementing our own test dummy using
webrick.
While adding a test, a bug was found, where an HTTP/2 connection
receiving a 421 response wasn't redirecting the request well to an
HTTP/1.1 one. This has been fixed by changing the way a new connection
is instantiated.
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)
