* Webmock allows users to stub a request using a URI with query
parameters, as a shortcut instead of using `with...`
* The Webmock adapter did not construct a URI that included the
`request.query`, causing stubs that had the same host/path, but
different queries, to return incorrect results
This type of lookup was guarded in the first DNS query lookup, however
after recursive CNAME queries, this could trigger a case where an AAAA
query would fetch cached A records, which would be filtered out but
still delivered.
Closs #184
when the early resolve path (using IP, /etc/hosts IP, IP from cache) is
followed, emit_addresses is called, and in a particular case (dual-stack
network but using an IPv4 address), the happy eyeballs resolution delay
path was activated when it shouldn't (it's meant to be used only for DNS
network requests), and resulted in @pool being called before it was ever
set.
This simple check ensures that it doesn't happen before it must.
Closes#182
for multi-backed resolvers, resolving is attempted before sending it to
the resolver. in this way, cached, local or ip resolves get
propagated to the proper resolver by ip family, instead of the
previous mess.
the system resolver doesn't do these shenanigans (trust getaddrinfo)
the early_resolve can't rely on separate by-family resolve logic.
Therefore, the addresses coming from there should be emitted with the
proper sort (ipv6 addresses last).
Also, fixed an issue with tcp connect where the socket wasn't being
reinitialized before the new attempt, thereby retrying to connec on the
same address that failed.
the ruby `resolver` library does everthing in ruby, and sequentially
(first ipv4 then ipv6 resolution). we already have native for that, and
getaddrinfo should be considered the ideal way to use DNS (potentially
in the future, it becomes the default resolver).
Two resolver are kept (IPv6/IPv4) along in the pool, to which all
names are sent to and read from in the same pool. IPv4 resolves are
subject to a 50ms delay (as per rfc) before they're used for connecting.
IPv6 addresses have preference, in that if they arrive before the delay,
they are immediately used. If they arrive after the delay, they do not
interrupt the connection, but they'll be the next-in-line in case
connection handshake fails.
Two resolvers are kept, but the inherent Connection will be shared,
thereby sending name resolving requests to the same HTTP/2 connection in
bulk. The resolution delay logic from above also applies.
Currently handles resolving via `resolv` lib. This happens synchronously
though, so we're not there yet.
