Hello,

1) I've met a problem with Digest HTTP authentication described in
this message back in 2006.

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)?

2) Let me also ask for advice. The intent is to use cURL as a client
library for monitoring HTTP resources. A client makes test connections
on schedule to simulate user actions and to check whether the resource
is available. It is correct to consider each connection attempt in
isolation and to use a new HTTP connection for it to trap problems
with DNS, TCP stack etc. that may get hidden when reusing the
connection. (I understand that generally reusing a connection is a
good approach but not in our specific task). 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?
Isn't 'still reuse a connection if it is necessary to complete an
exchange' a more appropriate behavior such as in case of NTLM and
Digest authentication even when CURLOPT_FORBID_REUSE option is set?

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?

Maybe a completely different scenario should be involved here? I
appreciate any advices.

regards,
Kirill
Received on 2008-05-26