On Sat, 4 Oct 2003, Daniel Stenberg wrote:

> On Fri, 3 Oct 2003, David Byron wrote:
>
> In the latest CVS, the existing check for this is around
> lib/transfer.c:540. It simply checks for a httpcode >= 400
> and the CURLOPT_FAILONERROR option.
>
> However, several of the new authentication schemes we support
> now, are expected to return one or even two 401 (or 407)
> response codes before the "actual one" is sent back. Only the
> last "actual" one should be subject to get checked if
> CURLOPT_FAILONERROR is enabled.

I tried moving to transfer.c (1.176) but got linker errors so I stuck with
1.173. If this is a problem, let me know what other stuff I need to get and
I'll move forward. I was hoping to avoid getting everything new.

This actually seems not so bad, although I don't know how it works with
other authentication schemes. I'm pretty sure more code is needed to deal
with them. Some of the code I wrote probably needs to be more general too.
The testsuite passes as far as it did before (but I haven't been running
with server SSL). This does work for me in the two cases I tested:

1. http (not https) with --ntlm and --fail and the proper username and
password
2. http (not https) with --ntlm and --fail and no username nor password

The first case works just the same as if --fail wasn't used. The second
case fails with error code 22. I looked for a more specific error code but
couldn't find one. Seems like there should be one but I'll leave that
decision for others/later.

Please let me know what you think.

Thanks much.

-DB

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf