curl-library
Choosing which IP to connect to (SSL verification/connection reuse issues)
Date: Thu, 09 May 2013 19:36:15 +0300
Hi,
Is there a way to tell curl to do connection caching per IP instead of per-host?
i.e. can I tell it to check its cache only *after* my OPENSOCKET_FUNCTION callback is invoked (which might change the IP)?
Background:
Given an https://example.com/something URL, where example.com points to multiple IP addresses
I want to be able to choose which IP address to connect to (for various reasons).
If this was HTTP it would be easy: just use the IP in the URL. However if I do that with HTTPS then certificate verification
fails as expected. I could turn off SSL_VERIFYHOST and do the verification myself, but I'd have to duplicate all of curl's
hostname verification logic and I'd rather not do that...
My current workaround is:
* keep the domain name in the URL: https://example.com/something
* override the IP address either by:
* using CURLOPT_RESOLVE example.com:443:127.0.1.1
* using CURLOPT_OPENSOCKETFUNCTION and changing the data in the *address pointer to point to my IP (127.0.1.1 in this example)
* SSL verification succeeds now (its using the domain name from the URL)
However this stops working as soon as I try to connect to more than one IP address with same hostname,with the multi interface:
* 1st call: OPENSOCKETFUNCTION callback changes IP for example.com to 127.0.1.1, this works
* next URL https://example.com, but I want to use 127.0.1.2 now
* curl will reuse the connection from the first IP (127.0.1.1) I've given it, and won't call my opensocket callback anymore
I could use CURLOPT_FRESHCONNECT to force a new connection, but then I won't be able to reuse my connection
with 127.0.1.1 ever. Would it help if I return the cached socket from OPENSOCKETFUNCTION callback,
and CURL_SOCKOPT_ALREADY_CONNECTED from CURLOPT_SOCKOPT_FUNCTION?
Thanks,
--Edwin
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-05-09