It was observed that, during a request done via a DoH resolve, the
resolver connection is left in the selector, despite already having
resolved the name, until the whole transfer is done. This is
inefficient, as we're not expected to use it again.
Fixed by improvinng the interest calculation of an HTTP/2 connection; if
the connection doesn't have anything to write. and there aren't any
inflight streams nor pings, connection won't be listened on.
Some debugging surfaced that the resolving step of doh contains 2
registered connections in the selector, instead of just one. That's
because both the resolver and its inherent connection are registered.
Fixed it by marking the resolver as closed, in the same way we do for
the system resolver, which also nnever gets registered in the selector.
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
The Errno::INPROGRESS error signals that the TCP handshake has been
signaled to the peer already, by which locally we just have wait for it
to be writable.
For simple plaintext requests, this was working correctly, because the
interest was always writable no matter what. However, when wrapped in
the SSL conn, and with the OS tcp stack under more stress, the interest
could be switched to readable, and by reuse, never reset; if, by
subsequent reconnection, EINPROGRESS would be emitted, the socket would
wait for readable instead, resulting in a loop and subsequent
connectionnn timeout.
although a connection might correctly emit an error response, the
returned responses are still defined by the fetch_response loop in the
session. When the pool is actually empty, this had the side-effect of
leaving error responses behind and exiting with just the first one.
This fixes it popping all available responses in such cases.
in some cases where the client is sending a request with a lot of bytes
(i.e. file uploads), and the server can't consume it (because
authorization, or wrong endpoint), the server stops processing the
request altogether and sends an error response immediately, in which
case the client should pivot and read the error response. Not doing this
was causing the Errno::EPIPE error. The mitigation is therefore to
rescue the error, and mark the consumption loop to read the response
immediately.
if a response does not advertise its body length, then the server closes
the connection when there's no more data to read. Therefore, the
HTTP/1.1 parser should interpret these conditions accordingly, and
emit the response.
Closes#114
two bugs were found. first, only file bodies would be rewinded, whereas
other rewindable (i.e. stringios and such) would be ignored. also,
part_index needed to be reset to 0, so that the parts would be flushed
sequentially (second request body was always empty).
a bug was found where in certain cases, a server responds with an error
before the request fully buffers the body. Under retries, the request
is reset, however, the http/2 conn handler kept the last chunk around,
which it would flush before writing the second request body, resulting
in byte-accounting issues. Therefore, response clean up request state
before yielding.
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.
