On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Daniel Stenberg <dan...@haxx.se> writes:
>
>> On Sun, 17 Mar 2013, Antoine Pelisse wrote:
>>
>>>> With redirects taken into account, I can't think of any really good way
>>>> around avoiding this init...
>>>
>>> Is there any way for curl to initialize SSL on-demand ?
>>
>> Yes, but not without drawbacks.
>>
>> If you don't call curl_global_init() at all, libcurl will notice that
>> on first use and then libcurl will call global_init by itself with a
>> default bitmask.
>>
>> That automatic call of course will prevent the application from being
>> able to set its own bitmask choice, and also the global_init function
>> is not (necessarily) thread safe while all other libcurl functions are
>> so the internal call to global_init from an otherwise thread-safe
>> function is unfortunate.
>
> So in short, unless you are writing a custom application to talk to
> servers that you know will never redirect you to HTTPS, passing
> custom masks such as ALL&~SSL to global-init is not going to be a
> valid optimization.
>
> I think that is a reasonable API; your custom application may want
> to go around your intranet servers all of which serve their status
> over plain HTTP, and it is a valid optimization to initialize the
> library with ALL&~SSL.  It is just that such an optimization does
> not apply to us---we let our users go to random hosts we have no
> control over, and they may redirect us in ways we cannot anticipate.
>

I wonder. Our libcurl is build with "-winssl" (USE_WINDOWS_SSPI=1), it
seems. Perhaps switching to openssl (which we already have libraries
for) would make the init-time better?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to