Re: [PATCH 2/3] http: add support for disabling SSL revocation checks in cURL

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> In any case, you can use "http.<url>.$variable" to say "I want the
> >> http.$variable to be in effect but only when I am talking to <url>".
> >> Does it make sense for this new variable, too?  That is, does it
> >> benefit the users to be able to do something like this?
> >> 
> >>     [http] schannelCheckRevoke = no
> >>     [http "https://microsoft.com/"] schannelCheckRevoke = yes
> >> 
> >> I am guessing that the answer is yes.
> >
> > Frankly, I do not know.  Does it hurt, though?
> 
> I did not and I do not think it would.  I was wondering if the
> ability to be able to specify these per destination is something
> very useful and deserves to be called out in the doc, together with
> ...

> >> I guess the same comment applies to the previous step, but I suspect
> >> that the code structure may not allow us to switch the SSL backend
> >> so late in the game (e.g. "when talking to microsoft, use schannel,
> >> but when talking to github, use openssl").
> 
> ... this bit.
> 
> > Crucially, this fails. The short version is: this is good! Because it
> > means that Git used the OpenSSL backend, as clearly intended.
> >
> > <skip if="uninterested in the details">
> > Why does it fail?
> > ...
> > </skip>
> 
> So there may still be some polishing needed, but as long as people
> are not using the "per destination" thing, the code is already good?
> That is something we may want to document.