Re: Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST

On 10/25/2012 12:36 AM, Kris Craig wrote:

On Wed, Oct 24, 2012 at 11:21 PM, Sherif Ramadan <theanomaly.is@gmail.com>wrote:

On Thu, Oct 25, 2012 at 1:46 AM, JJ <jawed@php.net> wrote:

On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan <theanomaly.is@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

So you propose to implement strict type checking of parameters because a few bozos don't read the documentation? That doesn't make much sense to me. What makes more sense is that the extension perform its own type checking where that is appropriate. I have plenty of subroutine code that checks what it was passed, it isn't difficult to do the job right instead of twiddling the language every time somebody complains. And by the way, is there any effort in-progress to make the basic subroutine calls more uniform, or are is_array() and isset() and friends going to forever remain underscore versus non-underscore? Perhaps I have no clue, but it sounded as though the language was to be changed to "fix" an error in an extension, 'scuse me if I'm talking out of my nether orifice.