On 02-11-12 12:52, Daniel Stenberg wrote:
> On Mon, 29 Oct 2012, Oscar Koeroo wrote:
>
>> With respect to the option 1 provided from the application; I can only see
>> four migration paths of choices in this:
>> a. treat a 1 as a 0, forced debug mode
>> b. treat a 1 as a 2, forced secure connection
>> c. arbitrate per SSL backend what best to do. For GnuTLS that means
>> treat a 1 as a 2, but for other SSL backends, treat it as a 0.
>> d. treat a 1 as an error and force people to change their code.
>
> ...
>
>> Given the paper option b is best and frankly I favor this.
>
> I don't because of what I already explained: Making 1 silently equal 2 will
> encourage people using the fixed libcurl to keep using 1 (or TRUE) as value,
> and then the copy-and-paste people will use such code on older libcurl
> versions as well and then they're back on the problematic route. It might
> even make the problem worse!
>
> I still advocate (d), but note that a large amount of programs don't check
> return codes so they won't notice and will just move on and use the default
> instead which is 2. An error is the only way that actually will push (some)
> people to replacing the 1s with 2s or 0s. Also, as has been discussed
> already, the number of programs that use 1 as a value is limited.

I see no problem with option d. This might indeed be best IMHO, especially
because it seems to be combined with the silent secure option b. as an effect.

In the beginning of the thread I thought you meant that the error would come
from the curl_easy_perform(). But if I read you answer carefully then you
are saying that the curl_easy_setopt(CURLOPT_SSL_VERIFYHOST, 1L) would fail
and this would then be combined with an internal treatment as if a 2 was set.

Did I understand this correctly? If so, go for it :-)

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-11-02