Potential Proxy refinements

Having taken a good look over the new proxy functionality I’m really impressed!

There’s a couple of things I’m interested in talking through…

• Could httpx/dispatch/proxy_http.py simply be httpx/dispatch/proxy.py?
• It would be nice if we could avoid exposing HTTPProxyMode. Alternatives could be…
  • tunnel=<bool>, forward=<bool> arguments (defaulting to None and doing sensible defaults on eg. tunnel=True|False.)
  • tunnel_only=False, forward_only=False arguments.
  • mode=<str>, and explicitly check for "forward" or "tunnel".
• I’d quite like to see ProxyDispatch compose ConnectionPool rather than subclassing it, as that ends up with a better seperation.
• Possibly have the docs link to some relevant places wrt. tunnelling vs. forwarding, since we’re using some pretty technical terms here without neccessarily giving enough context to users.

I’m happy to take on any of these bits myself, but figure they’re worth talking through first.

Also for reference, are proxies={"all:/...": ...} and proxies={"all": ...} conventions that are used in requests?

[sethmlarson]

Why would you tend towards removing the proxy_ prefix? They’re both proxies, just different methods of proxying. Users won’t see the modules anyways as the members are exposed top-level, the names are for our benefit.

And speaking of SOCKS, we’re implementing a lightweight sans-I/O SOCKS library without any dependencies unlike all current solutions so it can be marked as a dependency and SOCKS proxies will be first-class just like HTTP. 😃

[yeraydiazdiaz]

Closing this issue as the points have either been already addressed or are reflected in other issues in httpx and httpcore.