[sr-dev] http_async

Federico Cabiddu federico.cabiddu at gmail.com
Fri Feb 5 12:49:18 CET 2016


Hi Olle,

On Thu, Feb 4, 2016 at 3:30 PM, Olle E. Johansson <oej at edvina.net> wrote:

>
> > On 04 Feb 2016, at 12:23, Camille Oudot <camille.oudot at orange.com>
> wrote:
> >
> > Hi Olle,
> >
>
> It was Daniel’s recommendation to load the TLS module first since he
> had fixed some generic OpenSSL magic there.
>
>
Will add the recommendation to the doc.


> >
> >> - http_set_ssl_cert should have “tls” instead of “ssl”. SSL is bad.
> >
> > We spoke about this one, "ssl" reflects the names int the curl API. If
> > we totally disable SSL though, it makes sense to use "tls”.
> Exactly.


So does this mean that we are going to enforce the usage of TLS? Today it's
not the case anywhere in Kamailio and, sincerely, having a parameter with
"tls" in its name and then allowing the user to use ssl is misleading. I
would prefer:
1) not having any mention to ssl/tls in the name (like "http_set_cert")
2) raise a warning when the user tries to use a deprecated protocol version


> >
> >> - I still think we need to discuss the way you have to run functions
> >> to set parameters for a coming function call.
> >> (...)
> >> What if that function doesn’t happen, will all these values be reset
> >> for the next message processed in that process?
> >
> > Good point, that is not addressed yet: we have to figure a way to reset
> > all the values previously set when a new message is processed.
> > Currently, they are reset when the HTTP query is sent.
>
> And I think you need to rethink the way you handle this. We are quite
> open for new ideas, but adding a totally new scheme for setting parameters
> for
> function calls is not something we need - it will just be confusing for
> people who learn Kamailio. Please try to use an existing framework.
>
>
We will rethink this part.


> Sorry for being really, really, really stubborn of this, but I’ve spent
> over 10 years doing Kamailio trainings… :-)
>
> /O


No problem while the discussion is constructive, as it is in this case :)

Cheers,

Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20160205/e75adea9/attachment.html>


More information about the sr-dev mailing list