cURL / Mailing Lists / curl-users / Single Mail


Re: how to use --proxy-negotiate, exactly?

From: Brian J. Murrell <>
Date: Mon, 2 Mar 2009 04:31:42 +0000 (UTC)

On Sun, 01 Mar 2009 15:39:21 +0100, Daniel Stenberg wrote:
> Indeed. I think this is an issue worth persuing and fixing.


> This said, an app that would use more than one request would re-use the
> libcurl handle and thus retain the knowledge about the proxy and then
> not do round-trips for every subsequent request. It's just of course the
> fact that if you use curl it kills the connection all the time so it
> cannot do this...

Exactly. The repeated calls to curl was exactly the use case I was

> I think moving this thread to the curl-library list will increase the
> chances, not only that there will be a user like this but that we'll
> attract interest from a few other devs.

OK. If you want to move it, go ahead and I will follow.

> Assuming we can do that check for both HTTP@ and KHTTP@ we might still
> be able to get away with the single bit.

Indeed. I had thought about this a few hours ago myself. Keeping it
simple, we could change up the:

      /* if explicitly selected it isn't inited at this point */
      ret = Curl_input_negotiate(conn, proxy, auth);


      /* if explicitly selected it isn't inited at this point */
      if ((ret = Curl_input_negotiate(conn, proxy, auth)) < 0) {
        ret = Curl_input_negotiate(conn, proxy, auth);


in addition to a "neg_ctx->server_name = NULL;" in the "if(GSS_ERROR
(major_status))" condition at the end of Curl_input_negotiate() so that
subsequent calls will fall into get_gss_name();

The only side effect is the printing of a:

* gss_init_sec_context() failed: : Server not found in Kerberos database

When the KHTTP service name is attempted before falling back to the HTTP
service name. IOW, that error would display for every fetch where
Negotiate is needed rather than GSS-Negotiate. Not so great I don't

> If not, I don't see any reason
> why shouldn't add a bit if it makes or allows (lib)curl to behave
> better.

Great. We seem to be on the same page then. I'd surely like to avoid it
if possible, but am willing to accept another bit if no other clean way
can be found.


List admin:
Received on 2009-03-02