cURL / Mailing Lists / curl-library / Single Mail



From: Kamil Dudka <>
Date: Thu, 28 Jul 2011 12:11:50 +0200

On Wednesday 27 July 2011 18:43:41 Julien Chaffraix wrote:
> On Mon, Jul 25, 2011 at 3:28 AM, Kamil Dudka <> wrote:
> > Richard's proposal is now reflected in my incremental patch.  I am
> > attaching both patches to be applied.  CURLOPT_GSSAPI_DELEGATION now
> > takes values 0..2, 0 means 'no delegation' (default), 1 means 'delegate,
> > but only if the ticket has OK-AS-DELEGATE' as long as this is supported
> > by the GSSAPI implementation (otherwise equal to 0), and 2 means
> > 'unconditional delegation'.
> Just a couple of nits but it looks good to me. I guess Richard should
> be the one to weight in if he feels this meets his needs.
> * 0, 1, 2 don't make good options, I can't remember if it possible to
> use an enum on our options but I would favor that (at least
> internally). If not, named constants that people could use like:

The 0/1/2 approach was already being used by CURLOPT_SSL_VERIFYHOST and
CURLOPT_FTP_CREATE_MISSING_DIRS, so I just grabbed it from there.

> #define NO_DELEGATION 0L
> would make the API, documentation and code more readable.

Considering all the code that includes <curl/curl.h>, I do not think
NO_DELEGATION is a suitable name of macro to be used at global scope.
What about the following defines?


It would be consistent with the CURLSSH_AUTH_* options. Moreover, it allows
to combine both flags. Some web pages suggest that such a combination could
be useful:

> * It would be neat to mention GSS_C_DELEG_POLICY_FLAG in the
> documentation as this is an external dependency that we have and it
> will impact our behavior.

Fair enough.

> Maybe it could be a new feature as this is determined at compile time.

What would be the use case? We are running out of bits on CURL_VERSION_*.

I am attaching an updated version of the patches.


List admin:

Received on 2011-07-28