localstack wants me to create an account...

its downtime has  been a bit of a drag...

this allows running regression tests again in a dind container system,
which doesn't expose it to issues with nghttp2 again.

for chunked responses, it was preserving the decoder as the buffer, which broke subsequent response parsing in cases where the body wouldn't be parsed, such as in the case of HEAD responses with the transfer-encoding: chunked header

Closes #378

also, synching access to the token inside a session, as it may be used across threads

can happen in rate-limiter plugin scenarios if the date is in the past

before, a comparison like what is done to compare connections was done,
but this is not correct, as small differences, such as different origin
or path, should not matter, i.e. the resolver should do them the same,
as long as the resolver-related options (resolver class, cache, options,
etc) are the same).

the comparison of connections options which may match is also decoupled
from the main options equality operation.

so it can be reused

this has an adverse effect in multi-host multi-request situations, where in the context of a web server, retries or shutdown may be delayed because of premature context switching

this is anyway a problem of the ruby thread scheduler which needs to be smarter, and would only benefit situations where the pool max connections is set and is way lower than the number of threads

can be tcp low level packet ACK stuff, can be openssl...

in a scenario where multiple requests were being sent to a connection
which needs ping-for-liveness, several pings were being sent, even if
only one of them would get a response; this fix ensures that a single
ping is sent for the full batch.

now that we have this, we don't need to set the state in a dirty manner
in the pre-check.

spare a potentially needless round trip to the selector by doing so.

this is not a real fix, but it should hopefully help pinpoint the state of the connection at the time while not disrupting daily business

also, improve sig check by using local vars in dispatch flow.

`parser.handle_error` may, in some cases, disconnect the connection (by
calling `#reset`), which may make it available to another thread, which
may have already fiddled with the ivars.

to guard against it, before calling the method, the connection pending
list is copied into a local var and flushed.

this fixes an issue when raising RequestTimeoutError, as this timeout
may not be raised before the request traverses multiple connections (via
the persistent or follow redirects plugin), while the original callback
was being raised in the first connection the request was sent to.

This fixes it by keeping a reference to the current connection the
request is currently in; this reference is removed when the request
finishes, i.e. when the error response is assigned, or the response
finishes.

the main purpose of the test is to verify that the connection does not go down with protocol error, as there are cases where the server won't send any more chunks back, despite the client having sent data chunks that were ignored prior to reconnection

skip expect tests relying on delayed body delivery, as httpbin sometimes closes the socket after intermediate response

no real point

that jruby-openssl breaks the test server impl

this created a situation where the requests would be reenqueued when the connection would be reused after closed (persistent), which would cause these requests to be reenqueued later when transitioning the connection to idle

to ensure this requests are drained from the parser as the error is bubbled up to the connection

which the connection may have reset to 1 based on prior knowledge

also, and based on the disable pipelining flow, when resetting requests, transition them back to :idle before marking them as pending

this should mean that a connection reset back to idle as part of error handling, such as in the case of disabling pipelining for HTTP/1.1, so this skip is to avoid double-resetting

auth: only generate token on retry once for a given batch of requests

Closes #377

See merge request !443

the recent change to be able to resend multiple requests at a time on
the same loop handling block made the complexity of it spike to O(n),
where every request needs to be checked, including requests which have
already completed. benchmarks runs with 5k requests, and the impact
was noticeable enough.

this change fixes it by keeping a record of pending requests, where the
list is drained as requests are completed; the loop is also
short-circuited on the first pending request. this change improves a lot
the handling of HTTP/1.1 multiple requests, as they're ordered, which
means that there's a guarantee that no other request completed beyond
the pending one, it's however suboptimal for HTTP/2 connections, where
requests may arrive out-of-order, which may introduce delay
in triggering resending requests and other callbacks.

this avoids raising certain errors twice for a given request, such as timeouts

the previous fix made retries sequential again. it was therefore
insufficient and unsuitable.

this fixes it with a much more involved change:

* add a callback to requests, `on_response_arrived`, which is emitted at
  the same time that the "on(:response)" callback; this callback is then
  assigned to pending requests in the `#receive_requests` initial phase.
* the callback is called and adds the request index to a list, signaling
  to the loop that there are requests with a response to process; this
  ensures that indexes in the list do not map to a pending request.
* the callback only triggers on the "waiting for the selector" part of
  the loop, which ensures that new responses resulting from calls to
  `fetch_response` (usually errors) do not needlessly add the index of
  the current request back to the list.
* callback gets unassigned at completion.
* extra logic for the follow-redirects plugin case, which is the only
  one where different request objects may be created, and the main
  motivation for not reusing the `on(:response)` callback, to always call
  the `on_response_arrived` callback of the root request so that the
  `#receive_requests` logic is invoked.

this should hopefully help figure out what goes wrong under the CI circumstances

Plugins::Proxy::Parameters#can_authenticate? delegates unconditionally
to its authenticator, but Authentication::Basic deliberately omits
can_authenticate? — it is preemptive and always sends credentials
without consuming a challenge. When an HTTP proxy returns 407 to a
basic-auth :proxy request, the 407 retry guards in proxy/http.rb
reach the call and crash with NoMethodError.

The header-bag mismatch that makes this path reachable lives in
Plugins::Proxy::HTTP — ProxyParser#set_protocol_headers writes
proxy-authorization into the parser's local extra_headers, but the
407 retry guards check request.headers, which never sees it. So the
guard always passes for Basic, control falls into the re-auth branch
and invokes can_authenticate? on the missing method.

Fix the delegation layer to read "no can_authenticate? defined" as
"no, can't re-authenticate via challenge-response". Authentication::Basic
stays untouched. Digest, NTLM, and SOCKS5 paths are unchanged.
Forward-compatible for any future preemptive auth scheme.

Adds two regression tests: one exercises the bug (fails on master
with NoMethodError, passes with the fix), one guards the Digest
delegation path so it keeps working.

fix: define can_authenticate? on Authentication::Basic

See merge request !446

using functional test on request, instead of synthetic test on the impl class

a connection, when closed, triggers the `on_close` callback, which will
eventually deregister the io from the selectables list in the selector.
However, when this callback is triggered as a result of
`Connection#interests`, which is invoked while the selectables list is
being traversed via `Array#delete_if`, it was causing, due to the block
yielding true, the next element in the list to be wrongly deleted.

This is a bug in the implementation of `Array#delete_if`, reported here:
https://bugs.ruby-lang.org/issues/22021 . in the meantime, the
workaround is to verify again, whenever the io is identified as closed,
whether the object is still part of the selectables list.

Fixes https://github.com/HoneyryderChuck/httpx/issues/138

may leak private info from peer server

fix performance regression of #receive_requests recent loop change

See merge request !445

The age of a cached response is the time elapsed since it was last
generated **or** revalidated by the origin server.

it may still contain relevant data for the next request

Fixes #381

apply the same strategy as other HTTP clients.

Closes https://github.com/HoneyryderChuck/httpx/issues/141

rate_limiter: adapt jitter calculation so that interval is not lower that Retry-After

See merge request !449

instead of raising an error that the user must catch

the only case where open connections come from the pool is when they're external io objects passed via options

no public interface exposing it anyway

only merges with instance of self