On Mon, Mar 18, 2013 at 11:38 AM, Erik Faye-Lund wrote:
> On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano wrote:
>> Daniel Stenberg 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
On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano wrote:
> Daniel Stenberg 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
Daniel Stenberg 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 c
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
> 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 ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo in
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.
W
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 i
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
Daniel Stenberg 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 time.
Tha
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 i
On Thu, Mar 14, 2013 at 11:45 PM, Junio C Hamano wrote:
> Johannes Schindelin 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 thin
Johannes Schindelin 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 vs DEFAULT, given t
Hi Junio,
On Thu, 14 Mar 2013, Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
> >> I wonder whether we want to have something like this instead:
> >>
> >> flags = CURL_GLOBAL_ALL;
> >> if (prefixcmp(url, "https:"))
> >> flags &= ^CURL_GLOBAL_SSL;
> >> c
Johannes Schindelin 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 agreement.
--
To unsubscr
Hi Junio,
On Thu, 14 Mar 2013, Junio C Hamano wrote:
> Erik Faye-Lund 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)
> >
> >
Erik Faye-Lund 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 #define'
Erik Faye-Lund 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);
>
> - curl_global_init(CURL_GLO
On Thu, Mar 14, 2013 at 4:23 PM, Johannes Schindelin
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 Windows).
>>
>> Initializ
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 whe
On Thu, Mar 14, 2013 at 2:51 PM, 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 whe
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 origi
21 matches
Mail list logo
