Hi,

On Mon, Dec 7, 2015 at 5:21 PM, Dan Tsohar <DanT_at_radware.com> wrote:
> Hi,
> In my particular case, I am trying to perform NTLM authentication using the multi interface. I am creating easy handles with CURLOPT_FRESH_CONNECT=1 but I still see more than one socket being used per one easy handle occasionally.
> Specifically I am seeing calls to my sockate action callback with action=CURL_POLL_REMOVE with socket=X and then a subsequent call to the callback with the same easy-handle with action=CURL_POLL_IN and socket=Y.

This is old (been in my drafts for a while) but I'd like to comment
that I think this is kind of a bug (or at least confusing behaviour).
I actually think this is related to (old) known bug 37 (flagged as resolved).

The way we do NTLM may result unexpected reuse of connection because a
connection is not being attached to the request who started the NTLM
negotiation.
Therefore, it is possible for a request to initiate a new NTLM
connection and once it receives the NTLM challenge it may actually use
another (already authenticated) connection instead of answering to the
challenge via the first connection.

The problem is best demonstrated when specifying CURLOPT_FRESH_CONNECT
as it forces a new connection although reusable connections are
available, therefore once we get the NTLM challenge response, we pick
an old authenticated connection instead of finishing negotiation.
See little example code that demonstrate it, at:
https://gist.github.com/frenche/d6efd81c713dd2c0f47d

Initially, I've attempted to address this by trying to keep
'conn->inuse' set to true while negotiating NTLM so no other request
will use the connection.
However, this was too difficult to achieve correctly so I ended up
with a simpler approach to tag the negotiating request with the
connection to stick to, see:
https://github.com/curl/curl/pull/682

Regards,
Isaac B.
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-02-27