These are deadline oriented for the request and response, i.e. a write
timeout tracks the full time it takes to write the request, whereas the
read timeout does the same for receiving the response.
For back-compat, they're infinite by default. v1 may change that, and
will have to provide a safe fallback for endless "stream" requests and
responses.
The following improvements were done:
* only cacheable status codes are allowed now (200, 203, 300, 301, 410)
* only responses considered fresh are cached; fresh response means:
* no-store directive not present in cache-control
* response hasn’t expired (when s-maxage, max-age or expires are
present)
A certain behaviour was observed, when performing some tests using the
hackernews script, where after a failed request on a non-initiated
connection, a new DNS resolution would be emitted, although the
connection still had other IPs to try on. This led to a cascading
behaviour where the DNS response would fill up the connection with the
same repeated IPs and trigger coalescing, which would loop indefinitely
after emitting the resolve event.
This was fixed by not allowing DNS resolution on already resolved names,
to propagate to connections which already contain the advertised IPs.
This seems to address the github issue 5, which description matches the
observed behaviour.
resolvers
All kinds of errors happening during the select loop, will be handled as
abrupt select loop errors, and terminate all connections; this also
includes timmeout errors. This is not ideal, for some reasons:
connection timeout errors happening on the loop close all connections,
although it may be only triggered for one (or a subset of) connection
for which the timeout should trigger; second, errors on the DS channel
propagate errors to connections indirectly (the emission mentioned
above), wrongly (connections for different hostnames not yet queried,
will also fail with timeout), and won't clean the resolver state (so
subsequent queries will be done for the same hostname which failed in
the first place).
This fix is a first step to solving this problem. It does not totally
address the first, but i'll fix dealing with errors from the second
use-case.
A subtle bug slipped through the cracks, where if a resolve timeout
error happened, the connection would remain in the pool. Subsequent
requests to the same domain would activate it, although no requests
would go through it; the actual desired behaviour is to outright remove
it from the pool on such errors.
This was achieved by registering the "unregister_connection" callback
earlier. However, the connection accounting step would only trigger if
taking it out of the selector worked, meaning it had been registered
before.
This should complement the `:origin` option, in order to provide good
defaults to build REST SDKs around of.
Ex:
```ruby
HTTPX.with(origin: "https://api.this-product.com", base_path: "/v3.1")
```
In order to expose other auth schemes in proxy, the basic, digest and
ntlm modules were extracted from the plugins, these being left with the
request management. So now, an extra parameter, `:scheme`, can be
passed (it'll be "basic" for http and "socks5" for socks5 by default,
can also be "digest" or "ntlm", haven't tested those yet).
a regression from the 0.19.x series was omitting the proxy credentials
when passed directly as proxy options (instead of being part of the URI).
Closes#188
class overrides
the faraday adapter was relying on subclassing the session to load
custom plugins. this doesn't play well with other integrations
monkeypatching the original session class, such as datadog or webmock,
which redefine it. from now on, we not only defer the creation of the
custom until necessary, we also use Session#plugin
Fixes#187
previously, a connection could be created based on request options. The
main problem is that requests may have special headers, which would make
them assign its own connection due to the headers mismatch in headers to
the already open connection to the same origin. This, in certain
scenarios, coupled with the persistent plugin, cascades into multiple
connections to the same host which are never closed.
This fix ensures that connection initial options comes from the session.
This way, it'll never change (as connections exhaust). Alongside that,
matching headers was relaxed to only take into account headers which the
original connection knows, special request headers will then opt out
from this.
