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.
to 1
A check was introduced limiting the number of requests send at once.
However. the connection header was set to "close" as well, because
the accounting involved the number of concurrent connections allowed.
This is now fixed, by doing accounting separately.
authentication plugin
TIL that S3 does not speak HTTP/2 (cloudfront does). Also, AWS sigv4
verification breaks with pipelined requests, therefore, we have to send
them one at a time.
GCP does provide HTTP/2 support, so let's test there as well.
It's expected that this endpoint will be used i most cases for file
uploads, so both plugins will be important to improve throughput and
auth-fail-fast scenarios
this allows the aws-sdk plugin to pass a wrapped Aws::Credentials
downstream, which provides the username/password vars. this is
important, as some of the strategies, such as the web identity token,
also revalidate these parameters.
The ruby-tls gem hasn't received an update in 3 years, and haven't
actioned on issues that old, which leads me to believe it was abandoned.
Therefore, I now maintain this fork, and this allows me to quickly
identify issues.
The flow within the IO wrapper has been dealt with as well
An error arose in decompressing a GZIP body from an HTTP/2 response,
where the second-to-last DATA frame actually sent the last meaningful
data chunk, and the server emitted an additional empty frame with
`end_stream` flag.
This error was introduced in the transition to ruby 3 and RBS
refactorings, when the gzip inflater closes automatically once all the
advertised (in "content-length" header) bytes are successfully
decompressed. In the case described above, the empty chunk still dives
into the decompressor and passed to the now closed ZLib::Stream, which
triggeres an exception.
The fix is to halt decompression early in the chain. Response#write
already knows how to deal with empty frames, so the control should be
passed there.
Fixes#112
this wasn't as easy due to reliance on Request#bytesize, which was
calling File#size on the closed file descriptors, which raised an
IOError caught by the selector. Caching fixes it, and removes the
recalculations from the hot path as well.
