Interesting challenge.
Can you just use different curl multi handles?
--Daniel
Yes, I think this would work. But tracking more than one multi handle
is a difficult task. libcurl is optimized for the "add many easy
handles to one multi handle" approach.
Regards,
Michael
On Wed, May 27, 2015 at 1:10 PM, Michael Kaufmann <[email protected]>
wrote:
Hi,
I have a challenging scenario for libcurl. I want to connect with https to
a cluster of ADFS hosts (Active Directory Federation Services). These hosts
have the same hostname, but different IP addresses. For example:
- host.example.org, IP: 10.0.0.1
- host.example.org, IP: 10.0.0.2
When establishing a connection, I want to control to which host libcurl
should connect to (10.0.0.1 or 10.0.0.2) because the hosts have separate
user sessions.
Furthermore ADFS needs SNI, so it is necessary to use the hostname in the
URL (https://host.example.org). It is not possible to just use the IP
address (https://10.0.0.1/ or https://10.0.0.2/).
As suggested in many mails on this mailing list, I have tried to solve
this using CURLOPT_RESOLVE. I have found two problems:
- CURLOPT_RESOLVE is not a "local" setting because it pre-populates the
DNS cache. All easy handles that use the same multi handle share a DNS
cache. Setting different IP addresses for the same hostname using
CURLOPT_RESOLVE may therefore lead to race conditions.
- A "wrong" existing connection may get reused. libcurl only looks at the
hostname, and does not remember that the connection has been set up using a
special IP address with CURLOPT_RESOLVE. (I have not tested this, but I
have looked at libcurl's source code.)
It is possible to work around these problems by using CURLOPT_RESOLVE with
an artificial hostname in the URL, e.g. "
https://host.example.org-10.0.0.1/"; - but then the server drops the
connection, because the artificial hostname is also used for SNI. A libcurl
option to control the SNI hostname (and also the hostname used for the
server certificate checks) would make this workaround viable.
A "clean" solution needs to address the problems mentioned above:
- CURLOPT_RESOLVE should only affect a single easy handle
- A new option to control the connection cache's behavior (reuse based on
hostname only or reuse based on hostname + IP address). This may be
implemented in a more general way with a "label" (string) that gets
attached to a connection, and libcurl is only allowed to reuse connections
when the labels match.
What do you think? All ideas and suggestions are welcome.
Regards,
Michael
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
--
"We must remember that those mortals we meet in parking lots, offices,
elevators, and elsewhere are that portion of mankind God has given us to
love and to serve. It will do us little good to speak of the general
brotherhood of mankind if we cannot regard those who are all around us as
our brothers and sisters.”
--Spencer W. Kimball
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
