wasn't updating length, which made queries for #empty? return true
in cases where it shouldn't. this fix circumvents that by nullifying
inflaters, thereby ensuring that the default behaviour matches the mock
reality.

Closes #372

webmock: remove override of #decode_chunk

Closes #372

See merge request !432

this allows the rate_limiter plugin to override the method without patching the option and potentially overriding a client value

retries: moved extraction of retry_after interval to internal method

See merge request !434

Fix the command in test docs

See merge request !436

the IOError exception will get a specific overridable handling function
(which by default will do the same as the general one).

there may be requests in the pending queue

considering that these will get rerouted

the connection close flow was doing the following in order:

* purge (cleaning buffers, closing socket)
* disconnecting (which checks the connection back in)
* setting the state to :closed

the last 2 steps are the race condition, as after connection is checked
in, the context may be switched **before** the state is `:closed`; and
then context may be switched back to it and state will be set to
`:closed` when it should not, leaving the connection in a corrupt state.

the problem is exacerbated for persistent connections, which may be
checked out from the pool in a state other than inactive.

this fixes it by adding the concept of a post state transition internal
callback, so in the case of both `:inactive` and `:closed` transitions,
disconnection only happens after the state has been set.

also, scoping logs to session instead of connection.

not all IOs can be nonblocking, like stdout; also, fix tries counter by excluding reentrant resolve calls where a query may already be undergoing

chore: add specific io error callback

See merge request !437

specially for WINDOW_UPDATE, where current state of remote/local window
is now logged to bookkeep flow control accounting.

this will verify that, at this point, httpx continues to before request
data, despite the server already replying with a response and
half-closing the stream.

the connection may have had buffered data waiting for WINDOW_UPDATE
increments, and those may still be buffered after the peer closes their
end of the stream. this effectively nullifies that, while also send a
last data frame closing the client end of the stream.

on stream half-close, thrash buffered data on the parser

See merge request !433

Alexander Mankuta authored Feb 17, 2026 and Tiago committed Mar 05, 2026

The API follows Array API.

- `delete` allows deletion if individual cookies. These cookies have to
  be instances of Cookie class. The can be either previously manually
  created and added to the jar cookies, or cookies found in the jar.
- `reject!`/`delete_if` allows deletion with a block.
- `select!`/`filter!`/`keep_if` allows keeping only specific cookies,
  selected by the block, and removal of the rest.
- `clear` allows removal of all cookies, it also can remove cookies
  that would match a URI (similar to how `[]` selects cookies)

It should implement the following methods from CookieStore:

* #get(name_or_options) -> returns the first matched cookie
* #get_all(name_or_options) -> returns array of cookies
* #set(name_or_options, value_if_name)
* #delete(name_or_options)

this should simplify the task of creating a jar object to be manipulated
directly by the end user.

cookies plugin: CookieStore API

Closes #374

See merge request !435

this was the behaviour beforehand, and may cause some issue due to the premature exit by blocking the state machine

this ensures that request timeouts are cleaned up on reroutes, and timeouts won't be caught without a selector

supports streaming the request

the default headers are now loaded differently, in the options object; they get initialized before the supported formats are enhanced. one can't nullify for reinitialization, nor do_initialize make a difference in this case, as accept-encoding is there by default. this works around it by reinitializing the headers object in the plugin

 fixing return value of initialize_inflater_by_encoding to prevent needless plugin overrides in types

when a server responds with an Upgrade header, the session may or may
not be configured to handle it (via one of the plugins). if it isn't, it
should just move on and keep the same flow.

on a keep-alive connection though, the next request would be buffered by
the parser in an invalid state, because the parser itself wasn't being
reset after handling the upgrade payload bits and before bailing out.

Closes #376

this plugin provides the building blocks that all tracing integrations
should build on top of. all they have to do is pass a tracer object to
the options, which follows the tracing API:

* #enabled?(request)
* #start(request)
* #finish(request, response)
* #reset(request)

the whole tracing boilerplate is now handled by the tracing plugin.

This integration fixes a bug when establishing the request init time, as
requests were being initiated with the connection initialization
timestamp.

the error may happen due to some user-level block error, and in such
cases, the response's already there at the end of the "route retry
request" logic.

http1 parser: reset before bailing out upgrade requests

Closes #376

See merge request !439

new plugin: tracing

See merge request !440

for the same reasons as the last commit, if some error happens on send, return it immediately

this will the case where a given connection fails to use HTTP/1.1
pipelining, and on reset, the connection will retain that information
and not attempt it again.

considering that these will get rerouted

so that the connection can reroute them to a new one if necessary. this happens for HTTP/1 connections which send sequential requests, i.e. they'd stay in the @requests buffer and handled one by one, but not really considered pending internally

connection #force_close will now start by purging io and buffers, then reroute requests from parser, and only then, based on the pending requests list, decide whether to disconnect or not

which can be overridable by a plugin

connection: when idling, before resetting the parser, route any possible requests that became pending back to the connections

proxy sockets wrap other sockets, this chaining ensures they're all closed

the resolver may be picked up from the selector, where it ain't wrapped
by the multi proxy. and when early_resolve fails, it calls
early_resolve, which wouldn't work without this patch.

#close implementations rely on current state check first, so no point in checking for state before

the post-check is there for the case where httpx is used inside a fiber scheduler, and the state may have retransitioned because the resolver was reopened

for that to work, allowing native resolver to transition from idle straight to closed