Re: [PATCH v3] http: add support for specifying the SSL version
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 14, 2015, 17:21 UTC
- Message-ID
- <xmqqlhddiy5a.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <55CCBF6F.3070808@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
Show 11 quoted lines
>> 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".
Show 11 quoted lines
>> + 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?