curl-library
RE: --proxy-ntlm and --fail
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.htmlReceived on 2004-03-29