> > That said, as I mentioned above I would be fine with removing cookie > > jar persistence if that was necessary to secure a passing vote, since > > it's not our primary focus. > > Given the information regarding the TLS re-use, the cookie sharing is my > only remaining concern. In fact with cookie sharing disabled it might > not even be necessary for the user to choose an ID: Given that libcurl > does the heavy lifting, as a user I should only need a single share > handle and let libcurl figure out the details, no? A boolean “share > connections across requests” when initializing a CurlHandle should > probably sufficient.
I realized I completely forgot to respond to this point. I had actually considered this when you first mentioned that you did not like choosable persistent IDs, but I think we'd need to consider how this would interact with CURLOPT_MAXCONNECTS. A single shared handle would mean a user couldn't create separate connection pools, and so it may cause churn if the pool size wasn't large enough. I don't think that's an insurmountable problem, however. I will raise that as a part of a v2 discussion attempt if this fails to pass.
