I completely agree with Adam and others, we should not change the behaviour to add any magic.
The ext/curl api was made to stay as close as possible from the original libcurl api and it should stay the same (even if it's not always implicit). A lot of people are often referring to the libcurl C documentation to get more informations. Since it's supposed to be almost a 1 to 1 binding everything (even bad use of CURLOPT_SSL_VERIFYHOST with boolean) should work as expected without any magic. Pierrick On 25 October 2012 02:19, Adam Harvey <ahar...@php.net> wrote: > > On 25 October 2012 13:46, JJ <ja...@php.net> wrote: > > On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan > > <theanomaly...@gmail.com> wrote: > >> I understand there are people out there that don't read the > >> documentation and aren't aware of the difference between > >> curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); and curl_setopt($ch, > >> CURLOPT_SSL_VERIFYHOST, true); but still... I don't think this is a > >> good idea either. > > > > I highly doubt code that sets CURLOPT_SSL_VERIFYHOST => true meant to > > imply CURLOPT_SSL_VERIFYHOST => 1...which essentially bypasses host > > verification. > > They may have, even in spite of it being a bad idea, since that's how > boolean → integer conversion works in PHP. I don't think we can assume > that every single person who's written that line of code didn't check > whether CURLOPT_SSL_VERIFYHOST was a boolean or integer option. > > > According to libcurl, CURLOPT_SSL_VERIFYHOST => 1 is "not ordinarily a > > useful setting". > > I agree, but I don't think we can start arbitrarily changing well > defined type conversion behaviour for one corner case. The > CURLOPT_SSL_VERIFYHOST option has been documented as expecting integer > 0, 1 or 2 since at least April 2002 (and probably quite a bit earlier > than that), complete with the meanings of each value — there's only so > much we can do to protect developers from themselves. (In fairness, > the wording strongly recommending using option 2 only came in last > August thanks to Ilia, but nobody should have been treating the option > as a boolean option to start with.) > > Fundamentally, it's a bad API on the part of curl, but that's a > separate issue. There's nothing stopping somebody proposing a saner > API on top of libcurl (as Anthony did recently with the password > hashing API atop crypt()). > > In summary, I'm against changing ext/curl here. > > I do have a couple of specific comments on elements of the patch > itself in the event that the changed behaviour is wanted, but I'll > post those on GitHub, since it's probably a better UI for that sort of > granular discussion. > > Adam > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
