modparam connections are created directly from the modparam set function, but the config file is loaded during mod_init. I thought about preventing both at the same time, but it would require bigger changes. Therefore, at the moment, connections can be defined in both modparam or config file at the same time. Duplicates are already prevented by the curl_init_con function and will cause startup to fail. All the connections are still in pkg memory (I have not changed this) which limits some other features. E.g. reload from config file.

Thanks for adding this to the README! I haven't added support for boolean and enum types (verify_peer = yes, tlsversion=TLSv1.2), but if the documentation says it does, then it's a bug that should be fixed :)

TODO: - Add support for enum and boolean types where applicable - Specify default query parameters in config file - Prevent use of modparams if a config file is specified (warn? fail?)

Are there anymore renames to go in before the freeze? I will change the API function names (curl_connect => http_connect) sslversion => tlsversion? I had been using the same as used by curl, but perhaps we can abstract that

Hugh

-----Original Message----- From: sr-dev [mailto:sr-dev-bounces@lists.sip-router.org] On Behalf Of Olle E. Johansson Sent: 03 February 2016 15:43 To: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] git:master:e2a2128c: http_client: Add ability to load connection definitions from config file

On 03 Feb 2016, at 16:34, Hugh Waite hugh.waite@xura.com wrote:

http_client: Add ability to load connection definitions from config file

• All current modparam parameters supported
• Default values given as modparmas will be used if not specified in config
• TODO: Cannot load defaults from config file

Great!

What happens if I configure a file - do we disable the “httpcon” modparam and ignore them? If not, what happens if the connection is defined twice?

/O ________________________________ This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Xura, Inc. or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to security@xura.com. Thank You.