this adds a cache store which can be shared across processes.

This depends on `pstore`, and the file is stored in the tempdir in a
versioned file, to make sure that changes to the format won't impact
upgrades.

Closes #368

the parameters are the ones supported by the http-2 gem: `:weight`,
`:priority` and `:exclusive`.

this should be a timeout which stretches along interactions to get a final response, such as when they involve multiple retries or redirections

* adding interval type to abstract divmod dep
* replace as much of Numeric as possible
* selectable is loggable

among others.

support passing HTTP/2 stream priorities when building the request

Closes #344

See merge request !426

added resolve cache adapter API and memory cache

Closes #368

See merge request !428

total request timeout

Closes #308

See merge request !427

thes new options allow the session to preemptively invalidate and
discard the authentication header (x seconds after its first use).

mostly useful when the token generation is dynamic (or else it'd
invalidate the token for nothing).

on the `oauth` plugin, the value of the `"expires_in"` field in the
token response payload will be used to invalidate the access token ahead
of time too.

made assignment/access to ivars a bit more thread-safe too.

more lenient limits in the resolver cache api tests (being wiped out sometimes on multithreaded contention)

0.15.3  regression tests don't seem too great to maintain atm

returns a multi

auth: :reset_auth_header_expires_in/at options

See merge request !451

the `:cache` plugin, extracted from the `:response_cache` plugin, acts
as a subset of functionality which can be used to implement a custom
cache strategy, or other cache plugins (like the `:response_cache`
login, which now depends on it).

it's designed around 4 new callback options:

* `:cache_key ((request) -> String)`: returns a unique identifier where
  cache responses for the given request are stored
* `:cacheable_request ((request) -> bool)`: returns whether the request
  is cacheable and can use a cached response
* `:cacheable_response ((request, response) -> bool`: returns whether
  the received response can be cached
* `:valid_cached_response ((request, response) -> bool`: returns whether
  the (cached) response is still valid and can be returned.
* `:response_cache_store`: same as the `:response_cache` option which
  returns the store instance.

some of the options of functionality and options of `:response_cache`
plugin are moved to the new plugin as a result. renaming will follow
deprecation rules.

:cache plugin

See merge request !452

there is a bug related to ractors, cvars which reliable reproduces with
the test.

it has been reported in https://bugs.ruby-lang.org/issues/22083

they were returning the same value, nothing exponential about them

another constant moving somewhere else... insane

due to how fiber schedulers are implemented, context may be switched during an IO#close call, and if the connection is reused, it may have transitioned to another state (or several). therefore, the connection checks the IO or the pending buffer to know whether it's safe to disconnect, among other possible actions

similarly, the IO skips moving to closed if the immediate state after
calling Socket#close isn't the expected.

again, the fiber scheduler can raise errors from previouslty checked IOs later, and that may happen in any call yielding to the scheduler, which includes sleep

instead of waiting for them to go back to the selector and wait for the next tick

when two fibers are dealing at the same time with the same connection recover-from-exhausted flow, make sure they don't stomp each other's feet

mitigation for https://bugs.ruby-lang.org/issues/21918

It was observed that, since ruby 4.0, fibers may yield IOError due to a
socket that has been closed, despite it not be the socket that is
currently under monitoring, although it has been previously.

because of this, IOError's are checked against in cases where expected,
and it is assumed if the IO object isn't closed, then this was a
spurious wakeup for a no-longer-nmonitored IO (it may be closed but if
it has work to do, the same is implied).

Solves https://github.com/HoneyryderChuck/httpx/issues/129

this could lead to, in fiber scheduler situations, to the connection being switched across fibers with timeout set as 0, as previously it was only reset on close, which works ok for other cases

fix integration with fiber scheduler

See merge request !447

Jan Sandbrink authored Jun 01, 2026 and Tiago committed Jun 03, 2026

In cases where more addresses than on the default
denylist shall be blocked

    plugin(:ssrf_filter, extra_unsafe_ranges: ["1.2.0.0/16"])

Alternatively some ranges from the default denylist can be declared
as safe:

    plugin(:ssrf_filter, safe_private_ranges: ["2001:db8::/32"])

previously, it was perceived that a request span time was including the
time it takes to connect when the connection is not open. However, this
accounting was also being done for the cases where a connection would be
closed, and the start time would be the time that connection HAD been
opened the first time around, which in the case of persistent
connections, could have been a long time ago.

This changes the monitoring to account for that only if the connection
is in a connecting state (discards open and closed/closing connections).

It'll also include the ping time in cases where a connection needs to be
probed first, such as long-lived connections, as a blank space there
wouldn't be self-explainable either.

Jan Sandbrink authored Jun 05, 2026 and Tiago committed Jun 08, 2026

ip_addr.include?(other) raises an error when other is
not an IPAddr, but rather a HTTPX::Resolver::Entry, which
delegates to an IPAddr only.

We therefore cast the entry into a regular IPAddr before performing
SSRF checks.

builds on top of the :stream plugin to provide a block handling of SSE
messages

that should be an empty string

it was observed in recent jrubies that IO.select'ing a socket which may have data already in the underlying buffer won't be immediately selected and fail in the server sent events with retries. this fixed it

plugin: server-sent-events

See merge request !450

and max_response_header_value_size.

These are parse-time enforced thresholds, which when detected, will
immediately raise before resources are further consumed, thereby
avoiding resource exhaustion attacks.

Closes #383

default 2 seconds, acts as a less lenient timer around pinging an open
connection for liveness.

new options: max_response_body_size, max_response_headers,

Closes #383

See merge request !455

new option: :ping_timeout

See merge request !456

when the values from from proxy uri and are parsed by URI, these values will be percent-encoded, which may generate the wrong value when encoded back by any of the authorization methods