On Wed, 7 Nov 2018, Force.Charlie-I via GitGitGadget wrote:
Normally, git doesn't need to set curl to select the HTTP version, it works
fine without HTTP2. Adding HTTP2 support is a icing on the cake.
Just a FYI:
Starting with libcurl 7.62.0 (released a week ago), it now defaults to the
On Wed, 23 May 2018, Junio C Hamano wrote:
-> Accept-Encoding: gzip
+> Accept-Encoding: ENCODINGS
Is the ordering of these headers determined by the user of cURL library
(i.e. Git), or whatever the version of cURL we happened to link with happens
to produce?
The point is whether the order
On Tue, 22 May 2018, Suganthi wrote:
We may not be able to upgrade to 7.60.0 any soon, Is the fix present in 7.45
, in this sequence of code. Please let me know.
I don't know.
I can't recall any SIGPIPE problems in recent days in libcurl, which is why I
believe this problem doesn't exist
On Tue, 22 May 2018, curlUser wrote:
Again SIGPIPE is seen with curl version 7.45.0 with multi interface.
Backtrace shows :
...
Looks like SIGPIPE_IGNORE to be added in prune_dead connections or in
disconnect_if_dead? Can anyone comment on this.
I'm pretty sure this issue isn't present in
On Mon, 21 May 2018, Jonathan Nieder wrote:
Looking at the code here, this succeeds if enough memory is available.
There is no check if the given parameter is part of
Curl_all_content_encodings();
By "this" are you referring to the preimage or the postimage? Are you
suggesting a change in
On Mon, 26 Mar 2018, Johannes Schindelin wrote:
Can we *please* also add that OpenSSL 1.1.* is required (or that cURL is
built with NSS or BoringSSL as the TLS backend)?
We might consider adding a way to extract that info from curl to make that
work really good for you. There are now six TLS
On Fri, 23 Mar 2018, Loganaden Velvindron wrote:
+#ifdef CURL_SSLVERSION_TLSv1_3
+ { "tlsv1.3", CURL_SSLVERSION_TLSv1_3 }
+#endif
Unfortunately, CURL_SSLVERSION_TLSv1_3 is an enum so this construct won't
work.
Also, let me just point out that 7.52.0 is 0x073400 in hex and not the one
On Thu, 30 Nov 2017, Nicolas Morey-Chaisemartin wrote:
It would make sense to have a way to ask libcurl to URI encode for us. I'm
guessing there's already the code for that somewhere in curl and we would be
wise to use it. But to work wqith older version we'll have to do it
ourselves anyway.
On Thu, 30 Nov 2017, Nicolas Morey-Chaisemartin wrote:
This is due to the weird "[Gmail]" prefix in the folder.
I tried manually replacing it with:
folder = %5BGmail%5D/Drafts
in .git/config and it works.
curl is doing some fancy handling with brackets and braces. It make sense
for
On Thu, 24 Aug 2017, Jeff King wrote:
Oh good. While I have you here, have you given any thought to a curl handle
that has two half-duplex file descriptors, rather than a single full-duplex
socket? That would let us tunnel over pipes rather than worrying about the
portability of socketpair().
On Thu, 24 Aug 2017, Jeff King wrote:
I opened a bug upstream and they already fixed this.
https://github.com/curl/curl/pull/1820
Cool! That's much faster than I had expected. :)
Your wish is our command! =)
--
/ daniel.haxx.se (who landed the IMAP PREAUTH fix in curl)
On Fri, 24 Mar 2017, Lars Schneider wrote:
2. run your own buildbot and submit data using the regular github hook and
have buildbot submit the results back (it has a plugin that can do that).
We do solaris-builds in the curl project using that method (thanks to
opencsw.org) and some
On Fri, 24 Mar 2017, Lars Schneider wrote:
Most Git developers work on Linux and they have no way to know if their
changes would break the Git for Windows build. Let's fix that by adding a
job to TravisCI that builds and tests Git on Windows. Unfortunately,
TravisCI does not support Windows.
On Wed, 13 Apr 2016, Jeff King wrote:
However, I don't think even that would give you what you want. Because I
think that even if we provide a credential, curl will make an initial
request (presumably to find out which auth type it should use, but that
is just a guess). I don't know if there is
Hello good peeps!
I just ran head-first into a segfault that is fully reproducable for me but
I'm not at all fluent in these internals so I'm not the suitable person to
offer a fix. Let me instead offer you some fine details:
0. I'm on a Linux box: a reasonably updated Debian unstable.
1.
On Thu, 11 Feb 2016, Christoph Egger wrote:
+#if LIBCURL_VERSION_NUM >= 0x074400
That should probably be 0x072c00 ...
--
/ daniel.haxx.se
--
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
username in URL.
Asking lubcurl expert about that might not be a bad idea; Cc'ed Daniel
Stenberg.
It is correct that libcurl needs a username to trigger the use of HTTP
authentication - any HTTP authentication - due to how we once designed the
internals for this - but when using GSS
On Tue, 22 Dec 2015, Paul Smith wrote:
I grok that Git doesn't want to re-invent the wheel and that libcurl is
convenient. I just wonder if anyone knows of another wheel, that doesn't
come attached to an entire tractor-trailer, that could be used instead :).
But if you would consider
On Fri, 11 Dec 2015, Lars Schneider wrote:
the "url..insteadOf" git config is case sensitive. I understand
that this makes sense on case sensitive file systems. However, URLs are
mostly case insensitive:
Minor detail here perhaps, but...
I would object to URLs being "mostly case
On Fri, 30 Oct 2015, Jeff King wrote:
The goal makes sense. Why weren't we using CURLOPT_RANGE before? Did it not
exist (or otherwise have limitations) in 2005, and if so, when did it become
usable? Do we need to protect this with an #ifdef for the curl version?
CURLOPT_RANGE existed already
On Sun, 1 Nov 2015, Jeff King wrote:
While I have your attention, Daniel, am I correct in assuming that
performing a second unrelated request with the same CURL object will need an
explicit:
curl_easy_setopt(curl, CURLOPT_RANGE, NULL);
to avoid using the range twice?
Correct. As the
On Fri, 28 Aug 2015, Stephen Kazakoff wrote:
From:
curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
To:
curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_BASIC | CURLAUTH_NTLM);
I did however find the CURL documentation
(https://secure.php.net/manual/en/function.curl-setopt.php)
On Thu, 24 Apr 2014, Jeff King wrote:
Thanks, that's very helpful. I wasn't able to reproduce your problem
locally, but I suspect the curl patch below may fix it:
...
Daniel, I think the similar fix to curl_multi_cleanup in commit a900d45
missed this code path, and we need something like
On Tue, 18 Feb 2014, Jeff King wrote:
I think there is still an unrelated issue with curl_multi preventing
connection reuse, but I'm not sure from what you say below...
I'm not clear whether you mean by this that it is _expected_ in my test
program for curl not to reuse the connection. Or
On Tue, 18 Feb 2014, Jeff King wrote:
I'm not clear whether you mean by this that it is _expected_ in my test
program for curl not to reuse the connection. Or that curl may simply have
to do a little more work, and it is still a bug that the connection is not
reused.
Okey, I checked this
On Mon, 17 Feb 2014, Jeff King wrote:
Right; I'd expect multiple connections for parallel requests, but in this
case we are completing the first and removing the handle before starting the
second. Digging further, I was able to reproduce the behavior with a simple
program:
Yeah, given your
there are
connections to pick, otherwise it'll create new connections.
Daniel Stenberg (7 Jan 2014)
- ConnectionExists: fix NTLM check for new connection
Looks like you're just lucky as that above change first appears in 7.35.0.
But it seems there are some patches for older versions so
On Sun, 16 Feb 2014, Daniel Stenberg wrote:
Right, the problem is there to make sure that a NTLM-auth connection with
different credentials aren't re-used. NTLM with its connection-oriented
authentication breaks the traditional HTTP paradigms and before this change
there was a risk
On Mon, 25 Nov 2013, Jeff King wrote:
This is an extension to the fix in 7d80ed64e43515. We may call
Curl_disconnect() while cleaning up the multi handle, which could lead to
openssl sending packets, which could get a SIGPIPE.
Thanks a lot. I'll merge these ones in a second and they will be
On Sun, 24 Nov 2013, Jeff King wrote:
Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically placed
calls to ignore SIGPIPE. I wonder if there is another spot that needs
similar treatment. It looks like curl_easy_cleanup is covered, though, and
that's where I would expect
On Mon, 25 Nov 2013, Jeff King wrote:
Thanks. I'm having trouble reproducing the SIGPIPE locally, but I am able to
see via strace the write we make in curl_multi_cleanup. The call stack is:
curl_multi_cleanup
- close_all_connections
- Curl_disconnect
- Curl_ossl_close
On Sat, 12 Oct 2013, Eric Wong wrote:
This is a follow up to commit e47a8583a20256851e7fc882233e3bd5bf33dc6e
(enable SO_KEEPALIVE for connected TCP sockets).
Just keep in mind that TCP keep-alive is enabled in awkwardly many different
ways on different systems and this patch only supports
On Sun, 6 Oct 2013, Ilari Liusvaara wrote:
GSS-Negotiate authentication always requires a rewind with CURL.
Isn't 'Expect: 100-Continue' meant for stuff like this (not that it is
always supported properly)?
Yes it is and libcurl uses 100-Continue by default for that purpose. But the
harsh
On Sun, 6 Oct 2013, brian m. carlson wrote:
If there's a way to make Apache with mod_auth_kerb do that with curl, then
it doesn't require a change to git, and I'm happy to make it on my end.
But using the curl command line client, I don't see an Expect: 100-continue
anywhere during the
On Tue, 18 Jun 2013, Jeff King wrote:
But, I don't know if there is any multi-processing happening within the
curl library.
I don't think curl does any threading; when we are not inside
curl_*_perform, there is no curl code running at all (Daniel can correct me
if I'm wrong on that).
On Tue, 18 Jun 2013, Jeff King wrote:
TL;DR: I'm just confirming what's said here! =)
My understanding of curl's pointer requirements are:
1. Older versions of curl (and I do not recall which version off-hand,
but it is not important) stored just the pointer. Calling code was
On Tue, 18 Jun 2013, LCD 47 wrote:
Cloning with the git protocol works as expected.
A search on the net shows people having the same problem more than an year
ago, and the solution there seems to imply that Git can't cope with async
DNS in curl:
On Tue, 4 Jun 2013, Janusz Harkot wrote:
valid point, but from what you can find on the web, the only solution
provided everywhere was to disable certificate checking… so maybe that's not
me, but this is first time someone spent some time to check whats going on
:)
I don't disagree with
On Tue, 4 Jun 2013, Janusz Harkot wrote:
Strange was, that initial communication was OK (http GET), but when there
was http POST - git reported error (incorrect certificate). The only
workaround was to disable certificate verification.
My question is: does git support SNI on the https? If so
On Tue, 4 Jun 2013, Janusz Harkot wrote:
Which libcurl version and SSL backend is this? (curl -V usually tells)
$ curl -V
curl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r
zlib/1.2.5
From what I can tell, that OpenSSL version supports SNI fine and libcurl has
supported
On Tue, 4 Jun 2013, Janusz Harkot wrote:
What makes you suggest that's what's happening? Sure, if it would've sent no
or the wrong host name it would probably have that effect.
line:
[36] * Re-using existing connection! (#0) with host (nil)
Ah that. Yes, that's a stupid line to show (that
On Tue, 9 Apr 2013, Jeff King wrote:
git-remote-http does not touch the openssl code itself at all. We only talk
to curl, which handles all of the ssl (and may even be built on gnutls). So
if that is the problem, then I think it may be a libcurl bug, not a git one.
... and if/when you do
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
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
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
On Wed, 6 Mar 2013, Yves Blusseau wrote:
I have try with an old version of curl: 7.15.5 and with the latest in
development curl 7.29.1-DEV. But it seem that git-remote-http is compile
with the old one.
libcurl 7.15.5 is over 6 years old.
The support for socks[*]:// prefixes in proxy names
On Fri, 22 Feb 2013, Junio C Hamano wrote:
http_proxy=http://proxy.myco.com
https_proxy=https://proxy.myco.com
The problem is that libcurl ignores the protocol part of the proxy
url, and it defaults to port 1080. wget honors the protocol specifier,
but it defaults to port 80 if none is
On Fri, 19 Oct 2012, Shawn Pearce wrote:
The issue with the current code is sometimes when libcurl is opening a
CONNECT style connection through an HTTP proxy it returns a crazy high
timeout (240 seconds) and no fds. In this case Git waits forever.
Is this repeatable with a recent libcurl?
49 matches
Mail list logo
