Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Manage pool of connections based on credentials #4288
https://fetch.spec.whatwg.org/#connections specifies that user agents should create a separate connection per credentials. This allows greater security by enforcing a stricter boundary between e.g. authenticated and non-authenticated requests.
Is that something curl should consider for the
You can use the share interface already and just provide different connection caches for different requests, which would make them totally separate - which of course will satisfy that requirement at a loss of other connection sharing that won't happen. Not an ideal solution, but possibly a work-around.
To make such a feature use the connection cache effectively I really think it needs to be handled correctly and internally for each easy handle's use of the pool.
We already do separate connections for different credentials for pretty much all other protocols so a lot of the logic is already there. The options are perhaps:
HTTP authentication is not a widely used practice these days and I think that applications that mix authenticated and non-authenticated requests to the same host using libcurl are rare. I feel that these WHATWG guidelines are mostly directed to the major browsers rather than for transfer libraries.
oh indeed, thanks for the reminder!
that means separated cookies and TLS state, that's what you mean, isn't it?
That would be the most effective for the lazy me at least :)
I get your last point also. I don't have specific arguments to counter it...
Not necessarily. The share interface is basically a way to create a separate object that holds shared stuff (states and caches). Exactly what stuff to share you can decide yourself out of the available set. In my case I was thinking only the connection pool. Other things it can share includes cookies and DNS cache etc. It's a user choice.
Then you specify which easy handles that should use that specific share object. So, in a multi-using case you can have all handle's share cookies and DNS cache like "normal" but have each (specified) easy handle use the dedicated share object for its connection pool...