Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7331
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 26 Jan 2004 08:32:31 +0100
Message-ID: <200401260732.i0Q7WVq3024296@gw.kuantic.com>
To: sniper@iki.fi
CC: internals@lists.php.net
In-reply-to: <Pine.LNX.4.53.0401260700070.32154@ybpnyubfg.ybpnyqbznva>
	(message from Jani Taskinen on Mon, 26 Jan 2004 07:01:37 +0200 (EET))
References: <200401241340.i0ODegaq019260@gw.kuantic.com> <Pine.LNX.4.53.0401260700070.32154@ybpnyubfg.ybpnyqbznva>
Subject: Re: [PHP-DEV] Bug in conditional compilation in ext/curl/interface.c,
 PHP5.0.0B3
From: root@gw.kuantic.com (root)


Hi Jani.

BTW Digest Auth still can't be used in cUrl because of a bug in
libcurl. I've reported the bug to the libcurl mailing list but this
mailing list is not working at the moment at sourceforge.net.

FYI the bug is the following:

---------------------------
Hi there.

I spent some time trying to figure out why such a program does not work:

  curl = curl_easy_init();

  curl_easy_setopt(curl, CURLOPT_HTTPAUTH,CURLAUTH_DIGEST);
  curl_easy_setopt(curl, CURLOPT_USERPWD,"myusername:mypassword");
  curl_easy_setopt(curl, CURLOPT_URL, "soap_server_url");
  curl_easy_setopt(curl, CURLOPT_POSTFIELDS, "soap_request");

  res = curl_easy_perform(curl);

The problem is the following:

1) if CURLAUTH_DIGEST is used without CURLOPT_USERPWD, then a request
is made, but, of course, it fails because the user and password are unknown ;-)

2) if CURLAUTH_DIGEST is used with CURLOPT_USERPWD, then the request
is broken: the body is empty, without the post data. So the server
does not even reply with the nounce field...

3) I can have everything right if I force conn->user & conn->passwd in
http_digest.c, not using CURLOPT_USERPWD.

So there is something very strange going on when someone tries to set
user/passwd while using digest authentification.

I do not know libcurl enough to correctly locate the problem and offer
a nice fix, I'm afraid I could break something else.

I've just found that:

- In url.c, if I comment line 2009:

conn->bits.user_passwd = data->set.userpwd?1:0;
then I've everything okay.

OR:

- In http.c, If I comment lines 212-213:

        else if(conn->bits.user_passwd)
	  Curl_http_auth_stage(data, 401);

then it's also okay.

I can test any fix on a server with digest authentification if needed,
however I can not provide credentials to someone else since the server
is not mine.

However it is very easy to test the problem with any URL, even one
that does not exist, since one can see that the request is really
broken when both options are activated.

---------------------------

Cheers,

	Bernard