#300 Does not send Authorization: header when reusing connection

[Michael Churchill]

Submitted by: Mike Churchill churchil@hiwaay.net

SCOPE OF PROBLEM
-----------------------
Broken in 7.10.1 and 7.10.3 (and perhaps others). Get
401 error even when providing proper user:password
information

PROBLEM
----------
Can't retreive an .htaccess limited URL if a non-htaccess
URL requested earlier via the same connection. The
Authorization: line is not sent even if set for the 2nd URL
via CURLOPT_USERPWD.

HOW TO REPRODUCE PROBLEM
------------------------------------
Requested the robots.txt file from a site. Then
requested an .htaccess limited page from the same site.
Used:
curl_easy_setopt(curl_handle, CURLOPT_USERPWD,
UserPassword);
to set the user:password prior to the 2nd request.

If the connection is still open and therefore reused, the
Authorization: HTTP header IS NOT SENT.

If I pause long enough (via sleep() or running in
debugger and waiting long enough), then the connection
was closed and a new connection opened. This new
connection DID send the Authorization: line and fetch the
file correctly. Only when a connection is opened without
an USERPWD, and then is reused after setting the
USERPWD does the problem occur.

LIBCURL VERBOSE OUTPUT
-------------------------------
Here is the (sanitized) HTTP Request from the first fetch:
* About to connect() to www.somesite.com:80
* Connected to www.somesite.com (XXX.XXX.XXX.XXX)
port 80
> GET /robots.txt HTTP/1.1
Cookie:
Host: www.somesite.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, */*

* Connection #0 left intact
* Re-using existing connection! (#0)
* Connected to (XXX.XXX.XXX.XXX) port 80
> GET /restricteddir/ HTTP/1.1
Cookie:
Host: www.somesite.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, */*

* Connection #0 left intact

And this is what it looks like when the connection closes
between fetches (code remains unchanged):

* About to connect() to www.somesite.com:80
* Connected to www.somesite.com (XXX.XXX.XXX.XXX)
port 80
> GET /robots.txt HTTP/1.1
Cookie:
Host: www.somesite.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, */*

* Connection #0 left intact
((AT THIS POINT I PAUSED IN THE DEBUGGER FOR 1
MINUTE TO FORCE THE CONNECTION TO CLOSE, THEN
CONTINUED))

* Connection 0 seems to be dead!
* Closing connection #0

* About to connect() to www.somesite.com:80
* Connected to www.somesite.com (XXX.XXX.XXX.XXX)
port 80
> GET /restricteddir/ HTTP/1.1
Authorization: Basic dXNlcjp0aGVwYXNzd29yZA==
Cookie:
Host: www.somesite.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, */*

* Connection #0 left intact

((NOTE THAT THE AUTHORIZATION: LINE IS PRESENT
THIS TIME))

[Daniel Stenberg]

Logged In: YES
user_id=1110

Could you please provide us with a source code example that
repeats this problem using libcurl?

Then I can build a test case with it as input to repeat the
problem and then work on fixing it using that.

Thanks for reporting!

[Michael Churchill]

Logged In: YES
user_id=738542

run:
testprog
to see the problem, then re-run:
testprog sleep
(or anything as an arg)
to sleep between fetches (and close the connection as a
result). The second fetch WILL show the Authorization: line
in the HTTP request.

Note that 404 response for the second request is due to no
such file existing. When run accessing a real .htaccess site a
401 would result on the first run and a 200 on the second.

[Michael Churchill]

[Daniel Stenberg]

Logged In: YES
user_id=1110

thanks for the code

I'll debug this asap, but it might take a few days or a week
or so. I'll get back when I've done that.

[Daniel Stenberg]

Logged In: YES
user_id=1110

I took a dive in the libcurl code and I've now committed a
fix to CVS that I believe addresses the problem you're
experiencing. I would be happy if you could verify that this
fixes "your" bug. The patch is available at the URL below:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/curl/curl/lib/url.c.diff?r1=1.261&r2=1.262

[Michael Churchill]

Logged In: YES
user_id=738542

Daniel,
Yes, this does fix the problem, both in the test program I sent
you and in the original code.

Thank you.

[Daniel Stenberg]

Logged In: YES
user_id=1110

Bug report closed.

Thanks a lot for testing!