On Wed, Oct 24, 2012 at 11:21 PM, Sherif Ramadan <theanomaly...@gmail.com>wrote:
> On Thu, Oct 25, 2012 at 1:46 AM, 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. > > That's not our place to start guessing what the user did or did not > intend. The fact remains that a cast of a boolean true to int is in > fact 1. The fact also remains that CURLOPT_SSL_VERIFYHOST expects an > int as per the documented behavior. The fact additionally remains that > no user would expect var_dump((int) true) to return int(2). > > > > > According to libcurl, CURLOPT_SSL_VERIFYHOST => 1 is "not ordinarily a > > useful setting". > > > > Again, you're confusing users who don't read documentation and/or > don't understand it with users who may have fully read documentation > and understood it perfectly well and ever intention of setting > CURLOPT_SSL_VERIFYHOST to 1. > > I understand your intentions here are good, but we should not be > magically trying to guess what the user wants. We should document the > behavior clearly and this solution makes documentation completely > unclear. Nowhere in the PHP manual do we say "we might break the > promise of a boolean cast to int and make it int(2) instead of > int(1)". > > > - JJ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Correct me if I'm wrong, but 2 is already the default value, right? I've also seen plenty of cases where TRUE is mistakenly used instead of 2. I would also agree that this behavior is somewhat counter-intuitive. However, I think we'd be opening a can of worms if we started making arbitrary tweaks to change the documented behavior of third-party libraries. I think you do make a very good case for changing this behavior, but that case would (in my opinion, at least) need to be made to the folks over at libcurl, not here. That said, I can't think of any rational use-case for passing TRUE instead of 1. Every time I've seen this, the intended behavior was 2. What if, instead of changing the behavior, we have it throw a notice or warning if a boolean value is passed here? Because this is such a common error, I think it could be really beneficial in helping developers catch this early. Thoughts? --Kris
