CURLOPT_SSL_VERIFYHOST: stop supporting the 1 value

After a research team wrote a document[1] that found several live source
codes out there in the wild that misused the CURLOPT_SSL_VERIFYHOST
option thinking it was a boolean, this change now bans 1 as a value and
will make libcurl return error for it.

1 was never a sensible value to use in production but was introduced
back in the days to help debugging. It was always documented clearly
this way.

1 was never supported by all SSL backends in libcurl, so this cleanup
makes the treatment of it unified.

The report's list of mistakes for this option were all PHP code and
while there's a binding layer between libcurl and PHP, the PHP team has
decided that they have an as thin layer as possible on top of libcurl so
they will not alter or specifically filter a 'TRUE' value for this
particular option. I sympathize with that position.

[1] = http://daniel.haxx.se/blog/2012/10/25/libcurl-claimed-to-be-dangerous/

1 files changed, 3 insertions, 2 deletions

diff --git a/docs/libcurl/curl_easy_setopt.3 b/docs/libcurl/curl_easy_setopt.3
index 3b0dc6c9d..a388c2220 100644
--- a/docs/libcurl/curl_easy_setopt.3
+++ b/docs/libcurl/curl_easy_setopt.3
@@ -2323,8 +2323,9 @@ Curl considers the server the intended one when the Common Name field or a
 Subject Alternate Name field in the certificate matches the host name in the
 URL to which you told Curl to connect.
 
-When the value is 1, the certificate must contain a Common Name field, but it
-doesn't matter what name it says.  (This is not ordinarily a useful setting).
+When the value is 1, libcurl will return a failure. It was previously (in
+7.28.0 and earlier) a debug option of some sorts, but it is no longer
+supported due to frequently leading to programmer mistakes.
 
 When the value is 0, the connection succeeds regardless of the names in the
 certificate.