On Fri, 20 Apr 2012, Joe Mason wrote:

I'm sorry for my long delay in getting back to this topic.

> Add two new callback functions set through curl_easy_setopt (with associated
> userdata parameters):
>
> CURLOPT_HTTP_AUTHFUNCTION
> CURLOPT_HTTP_AUTHDATA
> CURLOPT_PROXY_AUTHFUNCTION
> CURLOPT_PROXY_AUTHDATA
>
> Both will have the prototype
>
> curl_authresult function(curl_authtype authtype, const char* const realm,
> int retry_count, const char* const last_failed_username, const char* const
> last_failed_password, void* userdata);
>
> authtype will by either CURLAUTHTYPE_HTTP or CURLAUTHTYPE_PROXY (so the
> client could use the same function for both callbacks).

Then perhaps we could limit this to just two options and "force" the
application to use the same function? I think we need to make an effort to
always restrict the number of options we add and this seems like an easy
way...

Also, I suspect we want to pass in a 'CURL *' handle too in the callback to
allow an application to possibly use libcurl functions (like your suggested
curl_easy_setcredentials) or just to figure out which easy handle the callback
is about.

> This covers all the cases I can think of. It's a little odd because AFAICT
> curl_easy_setcredentials is the first curl function that alters a handle
> while it's already conceptually in the middle of a request (although really,
> it's only allowed to be called between requests behind the scenes). The "if
> in this state, curl_easy_setcredentials does one thing; if in another state,
> it does something else" feels a bit complex. It also seems this would force
> curl to keep a lot of state around until curl_easy_setcredentials is called;
> I'm not sure how difficult that is.

We could possibly solve this partly by not prefixing the function name with
curl_easy_. As this function would ONLY ever be called from within this
callback it could be more special-cased like perhaps curl_cb_setcredentials()
and we can make it fail immediately if used outside of this callback.

> An alternate interface would have the client handle the state tracking,
> using an opaque handle to the data being used in the auth.

That seems to be a bit more complicated for the application though. Would it
really allow it anything extra?

To get a feel for which API that would suit us the best, I figure a good idea
would be to write a simple example source code that uses these imaginary APIs
and see how that code turns out. I mean, an API needs to be decently easy to
understand and write code for, not only be powerful.

I think one or two sample source codes will also be good to show to "the
world" and will allow us to more easily get more feedback and criticism of the
API and plans before we run ahead and actually implement any of them.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html