Daniel Stenberg [off-list ref] writes:
On Sun, 17 Mar 2013, Antoine Pelisse wrote:
quoted
quoted
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.
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano [off-list ref] wrote:
Daniel Stenberg [off-list ref] writes:
quoted
On Sun, 17 Mar 2013, Antoine Pelisse wrote:
quoted
quoted
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?
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Mon, Mar 18, 2013 at 11:38 AM, Erik Faye-Lund [off-list ref] wrote:
On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano [off-list ref] wrote:
quoted
Daniel Stenberg [off-list ref] writes:
quoted
On Sun, 17 Mar 2013, Antoine Pelisse wrote:
quoted
quoted
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?
It does indeed. So this is probably a better solution, and is
something we're considering doing in Git for Windows anyway (for a
different reason). Thanks for all the feed-back!