cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: --proxy-ntlm and --fail

From: Daniel Stenberg <daniel-curl_at_haxx.se>
Date: Mon, 29 Mar 2004 14:52:58 +0200 (CEST)

On Fri, 26 Mar 2004, David Byron wrote:

> This is what I'd like to do:
>
> - replace the code around line 581 of transfer.c that checks if k->httpcode
> >= 400 with a function called something like
> http_is_terminal_code(conn,k->httpcode).
>
> - implement http_is_terminal_code in http.c
>
> - part of http_is_terminal_code is easy. It's only when the code is 401 or
> 407 that it's a bit complicated.

Indeed. And only if you get 401 with data->state.authstage set to 401 or 407
when data->state.authstage is 407. As that variable is set to the number for
the particular "auth stage" it is currently in.

> Right now, it looks like this function will get called before
> Curl_http_auth_act.

If http_is_terminal_code() gets called immediately when the response code is
received it will be called before Curl_http_auth_act() yes, since
Curl_http_auth_act() is called when all response headers have been received.

> If this is true (and remains true), I think the only info I have to use in
> http_is_terminal_code is conn->data->set.httpauth and proxyauth.
> Unfortunately, I don't think that's right, or maybe not enough.

Right, it is not enough info since you cannot use the code only to determine
weather this is an error or not.

> Is it OK to just use httpauth and proxyauth? Do I need to use the other
> info? Am I close?

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.

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.

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html
Received on 2004-03-29