using libcurl 7.19.6 in conjunction with xmlrpc-c 1.16.3
If the server usses Kerberos via gss negotiate and valid credentials cannot be
obtained for the user then libcurl enters an infinite loop and never returns.
(As a side note the HTTP method when this problem was observed was POST)
The problem manifests itself when negotiate auth is picked, but we cannot
successfully obtian the user's credentials with
gss_init_sec_context(). Curl_input_negotiate() correctly detects the failure and
returns -1. However Curl_http_input_auth does not do anything when
Curl_input_negotiate() returns an error, this seems to be the crux of the
problem. I believe it should set the flag data->state.authproblem = TRUE when
Curl_input_negotiate() fails. Failure to set the authproblem flag causes the
infinite loop thusly:
output_auth_headers() is invoked, authstatus->picked ==
CURLAUTH_GSSNEGOTIATE, however negdata->context is NULL (because
gss_init_sec_context() failed in Curl_input_negotiate()) Thus
output_auth_headers() never adds the negotiate response to the output header
nor does it update any state.
multi_runsingle sees newurl and Curl_follow indicates it should loop again.
When it loops again Curl_http_auth_act() checks the data->state.authproblem
flag which is false, so it sets newurl believing we need another round of
The request is emitted (without any auth headers because
Curl_input_negotiate() previously failed) and the server responds with a 401
response indicating negotiate should be used. At this point the loop repeats
If Curl_http_input_auth() had set the authproblem flag to true when
Curl_input_negotiate() failed then Curl_http_auth_act() would have detected the
problem and the newurl would not have been set and thus the loop would
Attached is a patch which seems to solve the problem and to the best of my
knowledge does not adversly affect any other authentication logic in libcurl
(based on a careful examination of the program logic).