Bugs item #845941, was opened at 2003-11-20 23:23
Message generated for change (Comment added) made by pcvarma
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=845941&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: wrong behaviour
Status: Closed
Resolution: Later
Priority: 5
Submitted By: Josh Kapell (jkapell)
Assigned to: Daniel Stenberg (bagder)
Summary: fetching https, curl returns code 56 on 407 from proxy

Initial Comment:
libcurl returns error CURLcode 56 (CURLE_RECV_ERROR)
on 407 from proxy when fetching https resource.

libcurl version: 7.10.8
os: RedHat 7.3 (kernel 2.4.20)

When fetching an https resource from a proxy that
requires basic authentication curl returns error CURLcode
56 (CURLE_RECV_ERROR) when the proxy responds with
a 407 (proxy authentication required). This is
problematic as curl doesn't provide the 407 header
making it impossible to extract the challenge information
necessary (auth method & realm) to re-fetch. It seems
that curl should return CURLE_OK and then provide the
407 header & body which would be consistent with curls
behavior given an http url.

I've attached some code that will reproduce the bug but
you'll need to specify a proxy server requiring basic
authentication.

Best,

Josh

joshuakapell_at_yahoo.com

----------------------------------------------------------------------

Comment By: PC Varma (pcvarma)
Date: 2006-09-06 15:14

Message:
Logged In: YES
user_id=1394634

Similar/same issue
http://sourceforge.net/tracker/index.php?func=detail&aid=1233264&group_id=976&atid=100976

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2006-08-29 17:54

Message:
Logged In: YES
user_id=1110

libcurl still does not function properly if the connection
is dropped during a CONNECT negotiation of auth, no. This is
mentioned in the KNOWN_BUGS document and yes, we'd love to
have it fixed...

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-08-29 16:54

Message:
Logged In: NO

cURL version : 7.15.4
OS : Win XP SP2

I am using cURL for last 6 months. its working fine with
normal http/https communication. But its giving problems
"curl returns error CURLcode 56 (CURLE_RECV_ERROR) when the
proxy responds with a 407 (proxy authentication required)"
with https and "Microsoft Authnetication schemes" . The same
is working with http.

Is this bug still open from 2003-11-20 08:53? If it is
closed or any work-around please let me know.

Thanks in advance.

PC Varma.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2004-01-09 05:41

Message:
Logged In: YES
user_id=1110

This bug report is biw closed, and this issue is currently
marked as getting fixed for the 7.11.1 release (in the
TODO-RELEASE document). That is *NOT* the next release.

Thanks for your report and patience.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2003-12-17 16:50

Message:
Logged In: YES
user_id=1110

kjs42, you're talking about a different problem and it would
be a lot easier if you either filed this in a separate bug
report or brought the issue to a curl mailing list.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-12-17 04:18

Message:
Logged In: NO

In my case, I'm using NTLM auth on the proxy (MS Proxy 2.0
on Win2K Server). With HTTP, I can see in Ethereal that the
negociate, challenge and authentication is processed
correctly by LibCurl for CURLOPT_PROXYAUTH -
CURLAUTH_NTLM. But when HTTPS is used, it gives up early
with the '56' error, even though the proxy server is doing the
same dance of 407 responses to ellicit the correct NTLM
challenge/response.

I have verified that HTTPS works fine through the proxy using
IE 6 (the defacto test for NTLM proprietary auth). I wish my
customers would at least dump MS Proxy 2.0 for ISA, but so
far, I'm stuck trying to drill through MSP2. This limitation is
all that is keeping me from dumping the IE browser object for
a "more pure" experience for GET and POST of items.

Thanks,
Kyle
k j s 4 2 a.t. ya h oo .. co m

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2003-12-07 04:54

Message:
Logged In: YES
user_id=1110

1. I'll introduce a new error code indicating authentication
problems.

2. I'll make the proxy headers get passed to the callbacks
just like other headers are.

None of these are made yet, so I'll keep this report open.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2003-11-24 22:49

Message:
Logged In: YES
user_id=1110

I don't quite agree with your conclusions here.

Yes, it returns CURLE_RECV_ERROR and I would argue that it
should instead return some kind of AUTH error instead (when
the proxy returns 407). It would help users to understand
what the error really means.

The reason this is different from normal "return OK"
behavior of plain HTTP pages is that connecting to and using
a proxy is seen as part of the connection phase. I claim
that this is more of an error than getting a 404 back from a
remote server is.

Also, that's why you don't get the proxy headers back the
normal way. They're not part of the remote server's headers,
and if we provide them for the proxy they will mix with the
remote server's headers and it'll be confusing and return
different headers for users that happen to go through proxies.

But I recognize your problem and I do want to solve it. I
just can't think of any good way to do it using this
mechanism without breaking existing behavior... :-(

I think I need to give this some more thoughts.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=845941&group_id=976
Received on 2006-09-06