-
-
Notifications
You must be signed in to change notification settings - Fork 807
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mount API #977
Comments
Although this is new proposed API, I think it falls under the 1.0 cutoff, because it impacts stuff we want to resolve for 1.0. |
Since #1098, #1099, #1103, this has now become more obvious. I don't think we should support a Instead the API ought to look like this... client = httpx.Client(mounts={"http://www.example.com": WSGITransport(...)})
client = httpx.Client(mounts={"http://": MyCustomTransport()})
client = httpx.Client(mounts={"http://": MyCustomTransport(), "https://": MyCustomTransport()})
client = httpx.Client(mounts={"all://": MyCustomTransport()}) Additionally we could extend our URL pattern matching to also support the following... client = httpx.Client(mounts={"http://www.example.com/some/path/prefix": WSGITransport(...)}) At some point we might also want to think about exposing our pattern -> transport info from the client, since that'll help developers better understand what proxies and mounts have been introduced, and get a better internal model of how transport lookups operate. For example, perhaps we'd end up with something like this at some point... >>> os.environ["NO_PROXY"] = "example.com"
>>> os.environ["HTTP_PROXY"] = "localhost:1234"
>>> client = httpx.Client(mounts={"https://www.google.com/some/path": httpx.WSGITransport(...)})
>>> client.get_transports()
{
<httpx.URLPattern("https://www.google.com/some/path")>: httpx.WSGITransport(...),
<httpx.URLPattern("all://*example.com")>: httpx.SyncConnectionPool(...),
<httpx.URLPattern("all://localhost:1234")>: httpx.SyncHTTPProxyl(...),
<httpx.URLPattern("all://")>: httpx.SyncConnectionPool(...),
} (Note that I've renamed |
Somewhat related to #927, #954
We now have a really nicely defined Transport API. We also have the ability to mount proxies under particular schemes, or particular hosts.
Really we ought to be generalising that into a "mount a transport onto this scheme/domain/...".
Eg...
There's an equivalent API in requests... https://requests.readthedocs.io/en/master/user/advanced/#transport-adapters
Right now the closest we have is
proxies={<mount-point>: <Proxy or Transport>}
. However the set of mount points that are supported doesn't feel super well defined, and it nominally only supports proxies (even through they can actually be any transport instance).Here's a bit of a proposal for how a more consistent, and generalised mount API might look...
.transports = {'http': ..., 'https': ...}
read-only property on the client.transport
sets'http'
and'https'
..send
/.close
..mount(prefix, transport)
.Glossing over a bunch of stuff here since I just want to get the idea out there.
Ideally we'd also move away from having proxy transport instance be supported via
proxies = ...
, and instead only support the simple proxy config style forproxies=...
, with any more specific transport mounting handled via the.mount
interface so that there's only one way to do things.The text was updated successfully, but these errors were encountered: