A use case for per-request cookies with a Client (maybe they don't need to be deprecated?)

[ubernostrum]

Currently, passing cookies when making a request from a Client or AsyncClient will raise a DeprecationWarning:

Setting per-request cookies=<...> is being deprecated, because the expected behaviour on cookie persistence is ambiguous. Set cookies directly on the client instance instead.

The documentation says:

We prefer enforcing a stricter API here because it provides clearer expectations around cookie persistence, particularly when redirects occur.

But I'm not sure that the behavior is always ambiguous or that persistence is always what's desired when passing cookies to a request method.

The specific use case I have is unit testing of a web application, where I'm using a client bound to my ASGI application object to, effectively, be able to say "make a request to this URL on this ASGI app, sending these cookies".

And unfortunately I can't just, say, make a function-scoped pytest fixture that returns a client with a fixed set of cookies, because sometimes I do need to change the cookies during the course of a single test (say, to simulate what happens if a user logs in while in the middle of a longer sequence of actions). I suppose I could try instantiating one client per unique cookie set (so one that has only the non-logged-in cookies, one that represents the same user after a login, etc.), but given that some of them would make only a single request it seems a waste of a client instance and also a bit unwieldy to keep track of which client instances are bearing which cookies. Especially compared to the simplicity and clarity of just seeing the cookies being explicitly set on the appropriate request.

So I wonder if the semantic ambiguity hinted at in the deprecation warning could be resolved by breaking down the possible cases as:

• If a response is received which includes a Set-Cookie header, persist
• If one or more cookies are set on the client, persist
• If cookies is passed to a request method of the client, don't persist

At which point per-request cookies with a client might not need to be deprecated and removed? 🙏

[tomchristie]

I wonder if we might be able to provide for this by using httpx.Cookies and then setting the appropriate header directly on the request?

[rafalkrupinski]

How about automatically setting domain to cookies passed as a dictionary? This could be controlled by a flag, enabled by default for security.

[tomchristie]

Could be a good idea yep...

client.get("https://www.example.com", cookies={...})

Would set cookies on the client with the "www.example.com" domain, right?

[rafalkrupinski]

yep, this way redirects like /path -> /path/ work with simple dict cookies, but anything more fancy would need Cookie.set()

[rafalkrupinski]

Um, wait, on the client? You mean in the request?

[rafalkrupinski]

I can work on this, will I open an issue?

[rafalkrupinski]

Just linking #3071 , that removes per-request cookies altogether.

[rafalkrupinski]

Ah, links between issues and discussions don't show up...

[mxrch]

Hey, I agree with your point of view; sometimes we have an AsyncClient for efficiency, and need to send specific cookies in a single request without having to create another client for each request needing different cookies.
If this is really going to be deprecated, we would need another way to specify cookies in a request.
Otherwise, this is really just losing a very useful feature.