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(a)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(a)xura.com. Thank You.