On Mon, 29 Mar 2004, Daniel Stenberg wrote:

> I think perhaps we can make the "authdone" variable get a
> wider scope, and then that can also be used to determine
> this. If you are in authstage X (401 or 407) and you get a X
> and authdone is TRUE, then this is an error.

What I've done so far is just adjust the logic of the existing code to only
fail hard if the httpcode is >= 400 but not 401 or 407, and added a call to
Curl_http_should_fail after all the headers have been processed. This
seemed like the first incremental step. I could see removing the code to
check during processing of the first header line, but I thought I'd leave it
to minimize the changes.

All the tests still pass, and

$ ./curl -U domain\user:password -x <proxy server URL> --proxy-ntlm
http://www.google.com --fail

works. As in, I get the google homepage.

I'm guessing the right thing is to add some tests that exercise --fail (both
with and without authentication) to be a bit more confident that things are
working properly. I'll see if I can make some progress there.

If this is OK, I think the next steps for the code are:

- move authdone from the stack of Curl_http into struct UrlState.
- adjust Curl_http_should_fail to use the info in struct UrlState to decide
if there's an error.

> I can only see one problem with this approach and that is
> the existing known bug we have already: we don't properly
> recognize a server that wants to re-negotiate a Digest
> authenticaion. That will be made with a 401 (or 407) respone
> code while 'authdone' is TRUE... (and the WWW-Authenticate
> Digest line will contain a "stale=true" part that indicates
> exactly this re-negotiate request from the server - RFC2617
> section 3.2.1).
>
> So, there actually is no way to tell with 100% certainty
> that the response means "error" by reading only the response
> code.

One way to handle this is for the code that parses WWW-Authenticate for
Digest needs to store some extra state in UrlState for Curl_http_should_fail
to look at. How does that sound?

-DB