On Tuesday, August 20, 2013 4:52 PM, daniel.haxx.se wrote:
>I have what might be a first stab at a fix here locally. Will you be able
to do anything with it if I send you a patch to try out?
Yes, if you send it I will find time to try it out. Just point me to
instructions if applying a patch is n
On Tue, 20 Aug 2013, Kamil Dudka wrote:
+An easy handle already added to a multi handle was attmpted to get added a
+second time. (Added in 7.32.1)
There is a typo in the above statement: attmpted -> attempted
Thanks, I corrected that before I pushed this!
--
/ daniel.haxx.se
On Tue, 20 Aug 2013, Mike Mio wrote:
The 2 later versions take 1 sec. longer than 7.29 (which is very quick at
approx. 0.05 sec.). It seems that the delay is after the STOR and before the
data is transferred.
Yes exactly. I've kind of danced around that function for a while and tried to
only
Hi Again,
On Tue, 20 Aug 2013, Steve Holme wrote:
> I think it is safe to safe that it seems to be a problem
> when data is split over multiple packets.
>
> As such I'm now debugging ;-)
I think I might have been a little premature with that statement as the
"Written bytes, yy are left
Hi John,
On Tue, 20 Aug 2013, John Dunn wrote:
> > Out of interest what SSL provider were you using? You mention
> > a Visual Studio build of libcurl so I'm guessing either OpenSSL or
> > SSPI (SChannel).
>
> I think I've tried both. The curl.exe I tried was built with OpenSSL
> but my library wa
> Out of interest what SSL provider were you using? You mention a Visual Studio
> build of libcurl so I'm guessing either OpenSSL or SSPI (SChannel).
I think I've tried both. The curl.exe I tried was built with OpenSSL but my
library was built with SChannel so the issue might be independent of S
Hi John,
On Tue, 20 Aug 2013, John Dunn wrote
> Sorry about that. When I run my program I get three possible outcomes
>
> 1. Works without an issue
> 2. CURLE_OUT_OF_MEMORY with a partial read
> 3. timeout after 10 second with 0 bytes read
Interesting.
> > Are you able to reproduce the problem
On Aug 20, 2013, at 11:44 AM, Arun Victor wrote:
>> I did, obviously. It worked for me.
> ^^
> How did you add the cert to the Keychain and to which Keychain did you add it
> to? I tried adding it (in pen format) to various Keychains via Keychain
> Access to no avail.
Thanks Daniel for the patch for cert_stuff. It seems like the proper
solution. I'll look into taking that direction.
Also, thanks Kamil for the references. I'll need to look there more
carefully. It does seem that the issue boils down to allocations
in pem_CreateObject, and the references to finali
Hello Steve-
> Is it reliably the same size when you see the problem and what sizes are you
> having issues with?
It seems like the issue is if the data comes in multiple calls to the
CURLOPT_WRITEFUNCTION. The full email I am attempting to read is 1636 bytes. If
I get a callback with anything
Oscar, Nick - thanks for your responses.
>I did, obviously. It worked for me.
^^
How did you add the cert to the Keychain and to which Keychain did you add it
to? I tried adding it (in pem format) to various Keychains via Keychain Access
to no avail.
>If this site is a
Hi John,
> On Tue, 20 Aug 2013, John Dunn wrote:
> I was able to reproduce this issue using VS2010 both with a static and dll
> libcurl as well so it's not related to VS2012.
That's a relief, to a certain degree, as that's one version of Visual Studio
I'm not using - I compile for VC7.1, VC8, V
>> On Tuesday, August 20, 2013 5:53 AM, daniel.haxx.se wrote:
>> Can you for example try using curl to upload and use the --trace-ascii
and --trace-time to get detailed verbose logging with microsecond timing
resolution?
I certainly can. Here you go:
http://www.mentallyarranged.com/temp/dump_FTP
I was able to reproduce this issue using VS2010 both with a static and dll
libcurl as well so it's not related to VS2012.
-Original Message-
From: curl-library [mailto:curl-library-boun...@cool.haxx.se] On Behalf Of John
Dunn
Sent: Monday, August 19, 2013 4:01 PM
To: curl-library@cool.ha
Recent OpenSSL uses user interface abstraction to negotiate access to private
keys in the cryprographical engines. An OpenSSL application is expected to
implement the user interface. Otherwise a default one provided by OpenSSL
(interactive standard I/O) will be used and the aplication will have no
> On Tue, 20 Aug 2013, Dennis Clarke wrote:
>
> >Is there a place to get all the patch changes that happen after a
> release
> > similar to how we see patches to bash :
>
> We don't really have "patch changes" since a release. We have a stream
> of
> commits that after some months end u
Hi all,
As previously discussed and described, I've now introduced and commited an
alternative version of curl_easy_perform that uses the event-based API
internally. This is strictly for testing and debugging purposes - only present
in debug builds.
For a lengthier description and explanati
On Tue, 20 Aug 2013, Dennis Clarke wrote:
Is there a place to get all the patch changes that happen after a release
similar to how we see patches to bash :
We don't really have "patch changes" since a release. We have a stream of
commits that after some months end up in a new release. Betw
> On Tue, 20 Aug 2013, Gisle Vanem wrote:
>
> > A change in 'struct SessionHandle' broke the 'CURL_DOES_CONVERSIONS'
> > code in transfer.c:
>
> Thanks, pushed!
>
Is there a place to get all the patch changes that happen after a release
similar to how we see patches to bash :
ht
On Tuesday 20 August 2013 12:31:24 Daniel Stenberg wrote:
> Hi all,
>
> I'm about to introduce a new error code for the multi interface so I'm all
> ears for any feedback you might have on this!
>
> Doing curl_multi_add_handle() on an easy handle that is already added to
> a multi handle now retu
Hi all,
I'm about to introduce a new error code for the multi interface so I'm all
ears for any feedback you might have on this!
Doing curl_multi_add_handle() on an easy handle that is already added to
a multi handle now returns this error code. It previously returned
CURLM_BAD_EASY_HANDLE for
On Mon, 19 Aug 2013, Mike Mio wrote:
I modified your ftpupload.c example to upload and time a set of files. You
can see the difference between versions clearly.
I rather want to see exactly what details during a single problematic transfer
that take the time. Can you for example try using cu
On Tue, 20 Aug 2013, Gisle Vanem wrote:
A change in 'struct SessionHandle' broke the 'CURL_DOES_CONVERSIONS' code in
transfer.c:
Thanks, pushed!
BTW. Building with 'CURL_DOES_CONVERSIONS' gives me extra newlines in
CURLOPT_VERBOSE output. I cannot see why.
Hm, I'll see if I can dig around
On Tue, 20 Aug 2013, Jonathan Nieder wrote:
The series is pretty much as before. Changes since the rough draft:
Thanks again for your help. Here's a new version that uses aprintf
(thanks!) and uses Curl_safefree whenever they add a new free() of a pointer
that is not assigned some other va
On Tuesday 20 August 2013 10:39:02 Daniel Stenberg wrote:
> On Mon, 19 Aug 2013, Jerry Blakley wrote:
> > What seems to be happening is that while the session is open and the
> > connection reused, we make the repeated allocations in nss_create_object,
> > increasing memory usage, until the session
On Tuesday 20 August 2013 00:49:37 Jerry Blakley wrote:
> Our fusedav filesystem client uses cURL and nss. We create a thread, open a
> session handle (curl_easy_init), keep it open for many connections
> (curl_easy_perform), and close it when the thread ends (curl_easy_cleanup).
> Each call to cur
On Mon, 19 Aug 2013, Jerry Blakley wrote:
What seems to be happening is that while the session is open and the
connection reused, we make the repeated allocations in nss_create_object,
increasing memory usage, until the session ends and curl_easy_cleanup is
called.
Is this the case, and shou
libcurl truncates usernames and passwords it reads from .netrc to
LOGINSIZE and PASSWORDSIZE (64) characters without any indication to
the user, to ensure the values returned from Curl_parsenetrc fit in a
caller-provided buffer.
Fix the interface by passing back dynamically allocated buffers
alloc
This makes it possible to increase the size of the buffers when needed
in later patches. No functional change yet.
---
Unchanged.
lib/url.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lib/url.c b/lib/url.c
index 64d5add6..07555a90 100644
--- a/lib/url.c
libcurl quietly truncates usernames, passwords, and options from
before an '@' sign in a URL to 255 (= MAX_CURL_PASSWORD_LENGTH - 1)
characters to fit in fixed-size buffers on the stack. Allocate a
buffer large enough to fit the parsed fields on the fly instead to
support longer passwords.
After
Instead of nesting "if(success)" blocks and leaving the reader in
suspense about what happens in the !success case, deal with failure
cases early, usually with a simple goto to clean up and return from
the function.
No functional change intended. The main effect is to decrease the
indentation of
libcurl truncates usernames, passwords, and options set with
curl_easy_setopt to 255 (= MAX_CURL_PASSWORD_LENGTH - 1) characters.
This doesn't affect the return value from curl_easy_setopt(), so from
the caller's point of view, there is no sign anything strange has
happened, except that authenticat
Use appropriately sized buffers on the heap instead of fixed-size
buffers on the stack, to allow for longer usernames and passwords.
Callers never pass anything longer than MAX_CURL_USER_LENGTH (resp.
MAX_CURL_PASSWORD_LENGTH), so no functional change inteded yet.
---
Changes since v1:
- Simplifi
Instead of remembering before each "return" statement which temporary
allocations, if any, need to be freed, take care to set pointers to
NULL when no longer needed and use a goto to a common block to exit
the function and free all temporaries.
No functional change intended. Currently the only te
Jonathan Nieder wrote:
> The series is pretty much as before. Changes since the rough draft:
Thanks again for your help. Here's a new version that uses aprintf
(thanks!) and uses Curl_safefree whenever they add a new free() of a
pointer that is not assigned some other value on the next line.
T
Our fusedav filesystem client uses cURL and nss. We create a thread, open a
session handle (curl_easy_init), keep it open for many connections
(curl_easy_perform), and close it when the thread ends (curl_easy_cleanup).
Each call to curl_easy_perform eventually makes the following calls
(in nss.c)
A change in 'struct SessionHandle' broke the
'CURL_DOES_CONVERSIONS' code in transfer.c:
--- Git-latest/lib/transfer.c2013-08-20 06:52:36 +
+++ lib/transfer.c 2013-08-20 07:05:06 +
@@ -101,8 +101,10 @@
#ifdef CURL_DOES_CONVERSIONS
bool sending_http_headers = FALSE;
- if((con
37 matches
Mail list logo
