Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63614
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL+t6cEDORaPR5pauqDLL7vUxmL7=MiKQyD4YaLvsLXOg_kSRg@mail.gmail.com>
References: <CAB75mSX-cMqZPTfv2vc8fakD_pr31qPR+kO5_O=zYiVoy4xH2w@mail.gmail.com>
	<CAL+t6cF=e_55=v9bZVy7Tv=V3M4CUQLueu=b5Efa+MD0ewG_qA@mail.gmail.com>
	<CAB75mSVg10VURjFmOhNQk87CqVP9FOQmcSzzgfMUTEb6S7WvxQ@mail.gmail.com>
	<CAL+t6cEDORaPR5pauqDLL7vUxmL7=MiKQyD4YaLvsLXOg_kSRg@mail.gmail.com>
Date: Wed, 24 Oct 2012 23:36:55 -0700
Message-ID: <CAKOpQSwsNWkrN13LTJgWDqK+JVNZHCo==PJ7GFYAR5djE+TUMw@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: JJ <jawed@php.net>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=bcaec553ff42ea674604ccdc6d24
Subject: Re: [PHP-DEV] Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST
From: kris.craig@gmail.com (Kris Craig)

--bcaec553ff42ea674604ccdc6d24
Content-Type: text/plain; charset=ISO-8859-1

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

--bcaec553ff42ea674604ccdc6d24--