I don't remember of any change in other binding (not saying there were
not any) which like this one were removing a feature without giving an
alternative to do the same thing. If someone can point me to one, I'll
be glad to look at how we managed this.
Pierrick
On 20 December 2012 11:57, jpauli
On Thu, Dec 20, 2012 at 4:57 PM, Pierrick Charron wrote:
> Hi Julien,
>
> I think we need to trigger a notice to prevent users to write code
> that may not work in future version even if it doesn't depend on our
> changes but on libraries changes.
>
> Maybe we could be more explicit and tell the u
Hi Julien,
I think we need to trigger a notice to prevent users to write code
that may not work in future version even if it doesn't depend on our
changes but on libraries changes.
Maybe we could be more explicit and tell the user that the 1 value
will not be available as of libcurl 7.28.1 (I jus
On Wed, Dec 19, 2012 at 5:35 AM, Pierrick Charron wrote:
> Hi all,
>
> About 2 month ago, we had a discussion on this list about the fact
> that CURLOPT_SSL_VERIFYHOST was most of the time used with a Boolean
> value (true) instead of int values (0,1 or 2). This bad usage was
> leading to some sec
Hi all,
About 2 month ago, we had a discussion on this list about the fact
that CURLOPT_SSL_VERIFYHOST was most of the time used with a Boolean
value (true) instead of int values (0,1 or 2). This bad usage was
leading to some security issues. The result of this discussion was to
trigger a notice i
