On Mon, 26 May 2008, Kirill Senoshenko wrote:

> http://curl.haxx.se/mail/archive-2006-03/0030.html
>
> I use libcurl 7.18.0 and the problem is still there. I confirm the same
> problem with the NTLM authentication that also requires several HTTP
> turnarounds; the second turnaround opens a new connection to the default
> HTTP port 80 instead of a non-standard HTTP port indicated via
> curl_easy_setsockopt(CURLOPT_PORT) (I can see this with a Wireshark
> sniffer). Is there a bug tracker record for this issue (and any expectations
> when it may be fixed)?

I don't think there is "a bug tracker record" for this, nor are there any
particular "expectations" to be had as when it will be fixed. If you dive in
and help us out I'm sure we could squash it soon enough. libcurl is entirely
volunteer-developed on spare time.

A work-around for you would be to set the port number in the URL instead, as
we do that all the time and that works fine even for Digest and NTLM etc

It would help a lot if you could create a test case for the test suite that
repeats the problem. It would help us to get it fixed sooner!

> So we were initially using the CURLOPT_FORBID_REUSE option. This worked fine
> (closing the connection after each exchange) till we tried to add
> authentication support. Basic works as expected, but Digest and NTLM fail
> (in fact, NTLM hangs sending an endless flow of authentication messages to
> the server) because they need to use the same connection for the entire
> exchange and the library closes the connection due to CURLOPT_FORBID_REUSE.

> The question is, is it an intended behavior?

I would claim it to be a bug of some sorts, although not the easiest to
address. I mean, I figure the option should in this case not affect libcurl's
internal re-use and multi-pass auth code but it's a bit tricky. I think recent
modifications of that redirect-following code may in fact have made it simpler
to address this bug correctly.

Here too a test case that shows the problem would be appreciated.

> Next, I have found a workaround of using a CURLOPT_FRESH_CONNECT option
> before each exchange instead of using CURLOPT_FORBID_REUSE. This opens a new
> connection and allows all authentication messages to reuse it so Digest and
> NTLM succeed (except for case 1) explained above). So far so good. I have
> also set the CURLOPT_MAXCONNECTS option to 0 since I don't need the
> connection pool. The one minor issue is that cURL doesn't close my
> connection after the end of HTTP session and keeps it open till the next
> connection attempt (even though I have asked it not to use the connection
> pool). So at any point of time, I have open HTTP connections to all servers
> I am looking after. Can I avoid this and ask cURL or the server to close the
> connection after full exchange including the authentication stage and what
> API calls would achieve this goal?

CURLOPT_FORBID_REUSE would imply that. There's no explicit close function as I
can't see how it would make much sense. Of course I figure that
CURLOPT_MAXCONNECTS set to 0 could also be made to imply that the connection
should be killed after use since it really should be in the connection cache -
I mean that the current behavior could be seen as a bug.

-- 
  / daniel.haxx.se