On Wed, 10 Mar 2010, Petr Pisar wrote:

>> Thanks! It certainly seems like a decent approach to add. I miss the
>> documentation part of the patch (at least a rudimental description of how
>> it is to be used)
>
> If you meant to document this behaviour in user documentation files, you
> must point me where exactly (manual pages curl(1), curl(3); README,
> INTERNALS, MANUAL file?), or do it yourself. I'm sorry, I'm new to libcurl
> and I don't know the best place.

I don't know exactly, but perhaps the curl_global_init() would be suitable in
libcurl's end since that's the function that will do the magic.

For the curl tool there should be something mentioned in curl.1, I guess it
would be suitable to have it mentioned in association the SSL engine option.

> I have much better patch. OpenSSL exports CONF_modules_load_file(filename,
> ...) that loads filename config file or default one if filename==NULL.
> Following patch provides equivalent functionality :)

That's indeed nicer. But if NULL makes it load the default config file,
there's no way to make it load _no_ config file, right? I'm scared that this
code will change behavior of existing apps simply because it will find and use
some default config file lying around.

> BTW, second argument of CONF_modules_load_file() selects configuration
> profile from the file. Users would like to pass it either. We could define
> other environment variable.

I can think of arguments both for and against using the same name. But I'm
curious in learning what the WORST is that could happen if an app wrongly
would be made to load a config file (possibly by an inventive user). I'm
really not into these details and I've not yet had any answers to these
security-related concerns.

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