Dear Frank,
This is not the cURL mailinglist ;-). Also, cURL (as opposed to
https://gnunet.org/gnurl) supports about a dozen crypto backends,
so your problems may depend on the specific backend you had the
misfortune of linking against.
I have in the past experienced that some SSL libraries do not
play nice with certain other SSL libraries under certain
cipher configurations. So when you report such issues, you
should always be very specific as to which crypto libraries
with which cipher settings were involved on both sides. Often
the HTTP libraries (client/server) are not to blame, and
diagnosing such issues without detailed knowledge of the full
stack can be rather difficult.
Happy hacking!
Christian
On 06/17/2014 11:58 AM, Frank Meier wrote:
Hi
In our Application we normally do requests without HTTP keepalive
(CURLOPT_FRESH_CONNECT and CURLOPT_FORBID_REUSE set to 1).
Now when we use NTLM this does not work anymore with this settings. I
expected that libcurl would use the same connection for the NTLM
authentication (type1) request and the following "real" (type3) request
and then would drop the connection.
The problem then is, that libcurl is starting to loop indefinitely
unless CURLOPT_TIMEOUT is configured:
1) Libcurl sends request with NTLM type1 header
2) Server sends 401 with NTLM type2 header
3) Libcurl drops connection
4) Libcurl sends again a request with NTLM type1 header (and so on...)
When CURLOPT_FORBID_REUSE is set to 0 everything works fine.
In my opinion the connection should not be dropped after the first
request but one can argue, if CURLOPT_FORBID_REUSE is set, this is just
what happens. But If so why does it still work when
CURLOPT_FRESH_CONNECT is set.
In any case I think libcurl should not start looping and should abort
after the second request.
BTW I tested with version 7.37.0 and actual checkout from git
cheers Frank