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
On Mon, Mar 18, 2013 at 11:38 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
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
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
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
On Fri, Mar 15, 2013 at 05:23:27PM +0100, Daniel Stenberg wrote:
Thanks, then we should stick to starting from ALL like everybody
else who followed the suggestion in the documentation. Do you have
recommendations on the conditional dropping of SSL?
Not really, no.
SSL initing is as has
On Sat, 16 Mar 2013, Jeff King wrote:
But are we correct in assuming that curl will barf if it gets a redirect to
an ssl-enabled protocol? My testing seems to say yes:
Ah yes. If it switches over to an SSL-based protocol it will pretty much
require that it had been initialized previously.
On Thu, 14 Mar 2013, Junio C Hamano wrote:
As to ALL vs DEFAULT, given that its manual page is riddled with a scary
warning:
This function must be called at least once within a program (a
program is all the code that shares a memory space) before the
program calls any other function
Daniel Stenberg dan...@haxx.se writes:
(speaking from a libcurl perspective)
As for how ALL vs DEFAULT will act or differ in the future, I suspect
that we will end up having them being the same (even when we add bits)
as we've encouraged ALL in the documentation like this for quite
some
On Fri, 15 Mar 2013, Junio C Hamano wrote:
As for how ALL vs DEFAULT will act or differ in the future, I suspect that
we will end up having them being the same (even when we add bits) as we've
encouraged ALL in the documentation like this for quite some time.
Thanks, then we should stick to
Since ancient times, we have been calling curl_global_init with the
CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
stack on Windows).
Initializing SSL takes quite some time on Windows, so let's avoid
doing it when it's not needed.
timing of echo | ./git-remote-http.exe origin
On Thu, Mar 14, 2013 at 2:51 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Since ancient times, we have been calling curl_global_init with the
CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
stack on Windows).
Initializing SSL takes quite some time on Windows, so let's avoid
Hi kusma,
On Thu, 14 Mar 2013, Erik Faye-Lund wrote:
Since ancient times, we have been calling curl_global_init with the
CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
stack on Windows).
Initializing SSL takes quite some time on Windows, so let's avoid
doing it when
On Thu, Mar 14, 2013 at 4:23 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi kusma,
On Thu, 14 Mar 2013, Erik Faye-Lund wrote:
Since ancient times, we have been calling curl_global_init with the
CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
stack on
Erik Faye-Lund kusmab...@gmail.com writes:
diff --git a/http.c b/http.c
index 3b312a8..528a736 100644
--- a/http.c
+++ b/http.c
@@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url,
int proactive_auth)
git_config(http_options, NULL);
-
Erik Faye-Lund kusmab...@gmail.com writes:
I wonder whether we want to have something like this instead:
flags = CURL_GLOBAL_ALL;
if (prefixcmp(url, https:))
flags = ^CURL_GLOBAL_SSL;
curl_global_init(flags);
I do see that CURL_GLOBAL_ALL is
Hi Junio,
On Thu, 14 Mar 2013, Junio C Hamano wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
diff --git a/http.c b/http.c
index 3b312a8..528a736 100644
--- a/http.c
+++ b/http.c
@@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url,
int proactive_auth)
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hence my earlier suggestion (with the obvious tyop '^' instead of '~').
You will also find the information in my mail (unless you plonk my mails)
that ...
Our mails simply crossed. Comparing the two messages I think we are
in complete
Hi Junio,
On Thu, 14 Mar 2013, Junio C Hamano wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
I wonder whether we want to have something like this instead:
flags = CURL_GLOBAL_ALL;
if (prefixcmp(url, https:))
flags = ^CURL_GLOBAL_SSL;
Johannes Schindelin johannes.schinde...@gmx.de writes:
Apparently, ftps is also handled by cURL and most likely requires SSL.
How about optimizing for the common case and instead of prefixcmp(url,
https:)) ask for !prefixcmp(url, http:)?
I think that is a very sensible way to go.
As to ALL
On Thu, Mar 14, 2013 at 11:45 PM, Junio C Hamano gits...@pobox.com wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Apparently, ftps is also handled by cURL and most likely requires SSL.
How about optimizing for the common case and instead of prefixcmp(url,
https:)) ask for
20 matches
Mail list logo
