Context-managed client usage

#389 has seen some interesting discussions on context-manager usage of Client and AsyncClient, esp. https://github.com/encode/httpx/issues/389#issuecomment-536562376 and https://github.com/encode/httpx/issues/389#issuecomment-537111055. Figured it would be worth porting the discussion to a dedicated issue.

Retransmission of the two comments mentioned above:

@tomchristie

Context managed client instantiation

I’ve not yet seen any concrete evidence that backgrounding is strictly neccessary for HTTP/2 / HTTP/3 (vs. the alternative of allowing any background work to occur during any other interactions) I’m open to it potentially being a requirement, but I’ve not seen that throughly demonstrated at this point in time.

A good point of reference here would be to see how browsers treat HTTP/2 connections to hosts with open tabs - Do they continually ping them in the background? Does the behavior change for inactive tabs?

It’d be a fairly reasonable policy to allow connections to lapse with ping timeouts in cases where we’re not performing any network activity with the client at all.

Either ways around, something that I’d like to see addressed there is how the client instantitation pattern looks in a standard web app setup. To explain that it’s easiest to just work from the basic threaded case, and a bog-standard WSGI app, and ask “how does client setup look if you want to use a context-managed client instantiation?”

Typically in a flask app or whatever, if you wanted to use a single requests session for all outgoing requests you can do…

client = requests.Session()  # or httpx.Client()

Somewhere in some global app config, and then just import and use client everywhere.

I’m not sure how the pattern would look instead if you want to use a context managed with requests.Session() as client: ... block? (or httpx.Client() block.)

It makes more sense to answer that for the standard client / WSGI case, since it’s the simpler variant of the two, but still has the same requirement if you wanted strictly block managed backgrounding.

@sethmlarson

What are your thoughts on having the Client only allow HTTP/2 within async with blocks? We’re going to hit more issues with this when we try to implement HTTP/3 with retransmission alarms.

Let’s continue discussion here?

[tomchristie]

This thread https://github.com/python-trio/urllib3/issues/125 from @njsmith is nicely timed. Pretty much in line with how I’d see it.

[sethmlarson]

We have a cookiejar abstraction, I think setting it to an always-empty jar like you describe is best. 😃