>> What about adding the connection cache to the share object? The SSL
>> session IDs are already part of it, so adding the connection cache
>> seems reasonable.
>
> I always intended to have the connection cache to also be shareable
> with the share interface and I think it would fit the existing
> paradigms very well.

Thank you for your answer. Maybe I will create a patch for this.

>> For me, that's OK. Of course, a CURLOPT_RESOLVE that only affects
>> one single easy handle would be better :-)
>
> I completely understand that. I wouldn't mind introducing some sort
> of mechanism that allows this.

A callback function for the name resolution would be a powerful
mechanism. Similar to CURLOPT_OPENSOCKETFUNCTION, but a bit on a
"higher level". This new callback function should be able to either
return an address, or to tell libcurl to proceed with the normal name
resolution.

I still think that libcurl's connection cache should also look at the
addresses when reusing connections. This is useful for CURLOPT_RESOLVE
(it's possible to add and remove "name to address" mappings), and it
would also be useful for the callback function proposed above.

Regards,
Michael

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-06-02