these are interesting for browsers, but I can't seem to find a use-case for an http client. it was also breaks under HTTP/2, where the final response would have the 103 headers and the 200 response body
this had the effect of storing redirect responses and using them solely for inferences on the each chunk block, instead of the final response
Closes#282
when response would be called inside the #each block, the webmock trigger would inject the body before attaching the response object to the request, thereby retriggering #each in a loop
Closes#281
the last line of the payload wasn't being yielded unless the last character of the payload was a newliine. this was overlooked for a time due to stream plugin being built for text/event-stream mime type, which follows that rule, as per what the tests cover.
while stream requests are lazy, they were being nonetheless enqueued, before any function would be called. this was not great behaviour, as they could perhaps never been called, it also interfered with how other plugins inferred finished responses, such as the webmock adapter and follow_redirects. Another flaw in the grpc plugin was fixed as a result, given that bidirectional streams were actually being buffered
httpx uses throw/catch in order to save from so-called early resolve errors, i.e. errors which may happen before the name resolution process is either early-complete or setup, such as when there are no nameservers (internet turned off), and the requests were piped into the connection, which means they're outside of the 'on_error' callback reach. there errors were only covered on the initial send flow, i.e. in other situations when new connections may have to be established ad may early-fail, the throw would not be caught, and would reach user code
the name resolution code was making the usage of IPs dependent on the existence of a DNS resolver, but there are situations where users use the IP directly, and in such a case, when IPv4-only DNS is possible **but** IPv6 loopback/link-local is available, one should still provide support for it
this is an old vuln fixed in curl (https://github.com/advisories/GHSA-7xmh-mw7w-rr97), which has been fixed for a long time, where credentials via authorization header would be resent on all follow location requests; this limits it to same-origin redirects; an option, "auth_to_other_origins", can be used to keep original behaviour
stream responses weren't following redirects when both plugins were
loaded. This was due to the stream callback object not being passed
across the redirect chain.
