Re: [PATCH] A new option CURLOPT_GSSAPI_DELEGATION
Date: Sat, 30 Jul 2011 22:44:46 +0200
On Saturday 30 July 2011 20:55:54 Julien Chaffraix wrote:
> Indeed, however I usually prefer named constant as it makes the code
> more readable. This is likely something we will want to change someday
> for those 2 options.
I completely agree. Another use case would be to abuse one of the new defines
to #ifdef the code that calls ..._setopt(..., CURLOPT_GSSAPI_DELEGATION, ...)
without adding a new autoconf check. We cannot use CURLOPT_GSSAPI_DELEGATION
directly as it is an enumeral constant, not a define. I have already used
the approach in the xmlrpc-c patch, which is now pending inclusion of the
> > 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?
> > #define CURLGSSAPI_DELEGATION_NONE 0
> > #define CURLGSSAPI_DELEGATION_POLICY_FLAG (1<<0)
> > #define CURLGSSAPI_DELEGATION_FLAG (1<<1)
> > 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:
> > http://www.h5l.org/blog/index.php/page/2/
> I just mentioned some nits without thinking about the better way to
> implement it (you've also seen lately how good I was at naming
> stuff...). Your names are better and won't clash with anything else!
> > What would be the use case? We are running out of bits on
> > CURL_VERSION_*.
> I just thought it was an easy way to expose whether your library
> supports GSS_C_DELEG_POLICY_FLAG or not instead of having to look into
> your GSS API headers (with which you compiled the lib). There may be a
> way to expose the information using some of our generated headers. It
> is valuable IMHO to have a simple way of knowing that.
Well, my point was that the application did not have a choice anyway. If it
needs GSS_C_DELEG_POLICY_FLAG and the feature is not available, it simply has
to fail. A warning is produced so the user has some clue where to look for
I am not against adding a feature for this, but do not think this should be
considered a blocker for upstream inclusion. It can be introduced anytime
later. We are currently under pressure since the security advisory has
broken some stuff that used to work before. So I would prefer to just fix
the regression now and then tweak all the details that do not directly affect
the proposed API extension.
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2011-07-30