the remote one has been failing for some time

Options#merge works by duping-then-filling ivars, but due to not all of them being initialized on object creation, each merge had the potential of adding more object shapes for the same class, which breaks one of the most recent ruby optimizations

this was fixed by caching all possible options names at the class level, and using that as reference in the initalize method to nilify all unreferenced options

some more ivars which were not initialized in the first place were leading to the warning in CI mode

not sure anymore under which condition this was done...

while this type of error is avoided when doing HEv2, the IPs remain
in the cache; this means that, one the same host is reached, the
IPs are loaded onto the same socket, and if the issue is IPv6
connectivity, it'll break outside of the HEv2 flow.

this error is now protected inside the connect block, so that other
IPs in the list can be tried after; the IP is then evicted from the
cachee.

HEv2 related regression test is disabled in CI, as it's currently
reliable in Gitlab CI, which allows to resolve the IPv6 address,
but does not allow connecting to it

object shape improvements

See merge request !396

also, logging when a response is fetched in the session

This reverts commit f64c3ab5.

not really useful as telemetry metered, but would have been useful for other bugs

when a proxied ssl connection would be lost, standard reconnection wouldn't work, as it would not pick the information from the internal tcp socket. in order to fix this, the connection retrieves the proxied io on reset/purge, which makes the establish a new proxyssl connection on reconnect

when coupled with the retries plugin, the exception is raised inside send_request, which breaks the integration; in order to protect from it, the proxy plugin will protect from proxy connection errors (socket/timeout errors happening until tunnel established) and allow them to be retried, while ignoring other proxy errors; meanwhile, the naming of errors was simplified, and now there's an HTTPX::ProxyError replacing HTTPX::HTTPProxyError (which is a breaking change).

the routine was using #fetch_response, which may return nil, and wasn't handling it, making it potentially return a nil instead of a response/errorresponse object. since, depending on the plugins, #fetch_response may reroute requests, one allows to keep in the loop in case there are selectables again to process as a result of it

fix for issues blocking reconnection in proxy mode

Closes #337

See merge request !397

it has been quite unstable, 503'ing often

reduce exposure to httpbin.org even more

Closes #353

in a normal situation this would not happen, as events on a resolver would be dealt one at a time, but in a fiber-scheduler environment like async, the first query could be buffered in the 1st fiber switch, the second could then be enqueued on 2nd, then flush buffer and fiber switch on read, and a third query would then enter a corrupt state where, due to the buffer having been flushed on the 2nd fiber, write the 3rd query before receiving the second one, and messing up the pending query bookkeeping, making the fiber then block (due to DNS query never returning back) and expose that as an empty interest registration from some other connection on the selector

this is fixed by using @timer as a proxy for knowing that a given DNS query has been flushed but is still waiting on a response (or an eventual retry)

the decision to use IO.select was based on the number of selectables, however only on select_many the actual selectables would be prefiltered before being passed to it, in some cases meaning that only one descriptor would be passed to IO.select (instead of IO#wait_readable or the like)

in fiber-scheduler frameworks, this meant going a potentially more inefficient route needlessly, such as in async, where IO.wait_readable and the like are performed using epoll or kevent, whereas IO.select calls are executed in a background thread

do not check buffer before going to the parsers, which also take that account

for http2, use the http2 connection send buffer (instead of the connection buffer) to figure out whether it's waiting on a WINDOW_UPDATE, which is more correct and efficient

on http1, the logic is the same, but the code is simplified, as the checks become the same regardless of whether request or @requests.first is picked up

this is used downstream to inform the selector (via IO interest calculation) whether the connection should wait on events for the current fiber (i.e. the connection should be used for requests of the current fiber, or DNS requests for the connection of such requests must be pending)

https://bugs.ruby-lang.org/issues/21509

it was needlessly logging io information despite it not being taken into account for selection

http1: check interests also in the case where one of the pending requests is from the current context

this causes a very subtle bug where, in a multifiber scenario, when the last active stream is closed and the connection is checked-in, only to be checked out later and pinged for liveness, it may get caught in the termination flow of a session, which will try to deactivateconnections from the selector; given that only inflight requests were taken into account, it'd get deactivated and checked in, which would mess with the fiber which was actively using it

this fixes it by considering the ping state in the decision on whether the connection should be deactivated; when having an inflight ping, keep it open and in the selector

the previous patch was only considering the current inflight request and the pending requests, but in a scenario where multiple requests may have been buffered and considered in theory in-flight, this information would pass by, leading to a busy loop

Fixes and improvements for fiber scheduler integration

See merge request !395

https://github.com/jruby/jruby/issues/8917

same fix as done recently with #with, but different function

pool fix: when connection is acquired after waiting on it, return it immediately, instead of bookkeeping on max connections

the previous state was acquiring the connection AND reacting on the number of available connections

callbacks plugin: propagated callbacks to derived plugins

Closes #354

See merge request !401

plugin init fixes: enforce usage of Options or hash for the second argument; ensure that plugin only continues loading if it is a module or converts to one

pool fix: when connection is acquired after waiting on it, return it...

See merge request !402

plugin init fixes: enforce usage of Options or hash for the second argument;...

Closes #355

See merge request !403

this makes them extendable like other plugin classes, and the h2c plugin is rewritten to accomodate that requirement

so that those can be extended in plugins

this plugin is loaded into the persistent plugin by default, as it's already expected to work across fibers

same as in sequel

as the selectables array may shrink during the loop as a result

fiber scheduler concurrency plugin

See merge request !400

this acts as a delegator to ipaddr, and should be a drop-in replacement everywhere the ipaddress was used, with the extra information about expiration

adding TCP#addresses?, which drops on-the-fly expired entries, and therefore makes possible to DNS query for persistent connections

drop ip addresses from persistent connections which ran out of TTL

Closes #322

See merge request !404

in case the session has been used across threads, per-thread selectors are left scattered, and #close would have only closed the caller thread selector; this will traverse remaining threads and close all selectors for the given session; it does it in a bit racy way, but it's preferable to document when it's safe to call the function instead, as it's supposed to be a dangerous call anyway

this should also improve the before-fork callback in cases where the session has been used across threads

the way it was setup, the options class was object shape unfriendly, as the order of creation of ivars was dependent on input and undeterministic; this change fixes it by storing the option names in an array in the class, properly allowing it for extension on plugin calls, freezing it on demand when necessary, and using it to find unsupported options in cases where the former implementation didn't

some code was juggled to delay certain instantiations for later, and option_ setters are now private, as they should

connection reference should not remain in the response which goes to the user, as that may leak the reference which will block garbage collection of objects in the selector

options: fix object shape performance issues

See merge request !399

This was introduced in 7e9de9fa

Even if it is called after `private`, they don't inherit visibility.

Fix method redefinition warnings

See merge request !406

to not confuse with the system resolver, which uses getaddrinfo

response buffer: increase coverage, fix buffer dup when tempfile, simplify == as buffer always responds to read

resolver: adapt address intersection check to skip when original address list  may be empty due to expired check

there's already the request_error for that

not used anywhere. also, initialized an ivar in ssl class