From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 14 Aug 2015 17:21:37 GMT
Subject: Re: [PATCH v3] http: add support for specifying the SSL version
Message-ID: <xmqqlhddiy5a.fsf@gitster.dls.corp.google.com>
In-Reply-To: <55CCBF6F.3070808@web.de>

Torsten Bögershausen <tboegi@web.de> writes:

>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index 315f271..b23b01a 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -1595,6 +1595,28 @@ http.saveCookies::
>>  	If set, store cookies received during requests to the file specified by
>>  	http.cookieFile. Has no effect if http.cookieFile is unset.
>>  
>> +http.sslVersion::
> should this be https.sslVersion ?
> (http doesn't use ssl)

But there are sslCipherList, etc., already present, and more
importantly, I think you want http.proxy to apply even if you happen
to be talking http over SSL.

More importantly, given that we have the "limited to this URL"
mechanism "http.<url>.<variable>" that overrides "http.<variable>",
introducing "https.sslWhatEver" would force people to have two
configuration sections for no real benefit, other than silencing
pedants that want to say "these things should be defined only for
https".

>> + if (sslversions[i].name != NULL && *sslversions[i].name &&
>> !strcmp(ssl_version,sslversions[i].name)) {
>> +				curl_easy_setopt(result, CURLOPT_SSLVERSION,
>> +					sslversions[i].ssl_version);
> This is what my man page says:
>  CURLcode curl_easy_setopt(CURL *handle, CURLoption option, parameter);
> []
>
> RETURN VALUE
>        CURLE_OK (zero) means that the option was set properly...
> Should the return value checked (and we die() if we fail ?

Probably.  Do we check status from other calls to setopt?