headers
A. Craig West | 1 Feb 2009 03:01
Picon

Re: CURLOPT_HTTP_VERSION doesn't work?

2009/1/31 Daniel Stenberg <daniel <at> haxx.se>:
> For the sake of completeness here's my updated, resynced and extended
> version. Including updated test cases etc.
>
> Unless someone objects, I intend to commit this soonish.

It looks good to me, at least... I suppose I should look through the
test case code, it does seem pretty useful.
-Craig
Permalink | Reply | 0 comments |
headers
Jonathan Morley | 2 Feb 2009 09:38
Favicon

Re: LibCurl FTP upload is running very slowly..

Hi Daniel,

I am re-using the same handle, and I downloaded the latest version of
LibCurl. I don't doubt that it's probably my fault for using LibCurl
incorrectly. I was just asking for help, not trying to blame your library.

Whatever is causing it (my incorrect use of the library or something else),
it is running slowly and closing the FTP connection after every command,
despite my reusing the LibCurl easy handle. I am pretty sure it's not the
physical network or transport layer as I am using the FTP server on my local
machine via 127.0.0.1, so the request should not even be getting to the
physical layer. I set up some tests to make multiple, sequential, requests
to the FTP server (several upload operations to the latest version of
filezilla) without including the rest of my program, to make sure it wasn't
something in my main codebase. The code in the tests still opened a new
connection to the server and closed it after each curl easy perform
operation despite me reusing the easy handle.

Maybe this is filezilla, maybe it's my code somehow, whichever it is, I
tried a different library yesterday and it worked fine so I will have to use
that instead of LibCurl, at least for now, as I have time constraints around
the job I am currently doing. I will try and switch back to LibCurl and do
some more investigation when time permits.

Thanks,

Jonathan
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 2 Feb 2009 11:05
Picon
Favicon
Gravatar

Re: Porting HTTP cURL

On Mon, 2 Feb 2009, हर्षद नटीये wrote:

> I want to use  only HTTP feature of cURL.

Using curl or just port libcurl? Either way, curl-library is probably a more 
suitable list to get help with this stuff on. I'm cc'ing my response over to 
that list to get us started there easier.

> Which files need to be ported so that I can use cURL(only HTTP feature) on 
> other OS.

If your OS is *nix-like or at least has a decent *nix-like shell, you'll run 
configure and it should output a decent start already there.

If your OS is more special than so, then I advice you to hand-edit a 
lib/config.h version based on what lib/config.h.in contains. There are a few 
hand-edited ones in the source archive you can use as guidance.

To make it HTTP-only, you can define the HTTP_ONLY define in your config.h or 
makefile. Or you disable all the specific protocols with CURL_DISABLE_[proto] 
defines.

I advice you to simply work with defines/undefs as far as possible and build 
all source files (as those without the necessary defines set will be skipped 
"automatically").

If you get problems, do ask more specific questions on the exact problems you 
face. And please take those to the curl-library list then.

docs/INTERNALS and docs/INSTALL contain some general hints and clues that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yang Tse | 2 Feb 2009 13:57
Picon

Re: secur32.lib on Windows?

2009/1/31, Markus Moeller wrote:

> I am using VC++ 2008 Express and in my initial tests I created
> my own makefile.vc9 out  of makefile.vc6.

> Now I tried to use just vc6curl.dsw with VC++2008 to create
> a curl executable as a clean reference build before enabling
> socks_sspi but failed.

> VC++ 2008 converts the dsw file but I get either (using libcurl DLL):
>
> Compiling resources...
> Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
> Copyright (C) Microsoft Corporation.  All rights reserved.
> Linking...
> LINK : fatal error LNK1181: cannot open input file 'libcurl_imp.lib'
> Build log was saved at
> "file://d:\BuildArea\curl-7.19.4-20090130\src\DLL-Release\BuildLog.htm"
> curlsrc - 1 error(s), 0 warning(s)
> ========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
>
> or (using libcurl LIB):
>
> Compiling resources...
> Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
> Copyright (C) Microsoft Corporation.  All rights reserved.
> Linking...
> LINK : fatal error LNK1181: cannot open input file 'libcurl.lib'
> Build log was saved at
> "file://d:\BuildArea\curl-7.19.4-20090130\src\LIB-Release\BuildLog.htm"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Scott | 2 Feb 2009 18:05
Picon
Favicon

Re: CURLMOPT_MAXCONNECTS

I just ran valgrind and found that all the non-cached connections were
leaked. I call curl_easy_cleanup for each handle and then
curl_multi_cleanup at the end. In curl_easy_cleanup, ConnectionDone is
called for the connection and lastconnect is set to connectindex
(which is -1). Could there be a legitimate leak here?

Patrick

On Sat, Jan 31, 2009 at 7:16 AM, Daniel Stenberg <daniel <at> haxx.se> wrote:
> On Fri, 30 Jan 2009, Patrick Scott wrote:
>
>>> All easy handles must be closed with curl_easy_cleanup() and the multi
>>> handle with curl_multi_cleanup().
>>
>> I do call curl_easy_cleanup for each handle that finishes. What if I
>> can't call curl_multi_cleanup for a long time? Do those dangling
>> connections stick around until I do?
>
> Yes. The connections are either closed after use or cached in the multi
> handle.
>
>> Where are they stored until they are cleaned up if they are not in the
>> cache (I'd like to do some hacking of my own around parallel connections and
>> pipelining)?
>
> An easy handle is the "owner" of the connection until the transfer is done,
> and then it is handed back to the cache (which is kept in the multi handle
> by default when you use that). If the connection didn't fit the cache due to
> size restrictions it will instead get closed and all resources associated
> with it are freed.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Stenberg | 2 Feb 2009 19:16
Picon
Favicon
Gravatar

Re: CURLMOPT_MAXCONNECTS

On Mon, 2 Feb 2009, Patrick Scott wrote:

> I just ran valgrind and found that all the non-cached connections were 
> leaked. I call curl_easy_cleanup for each handle and then curl_multi_cleanup 
> at the end. In curl_easy_cleanup, ConnectionDone is called for the 
> connection and lastconnect is set to connectindex (which is -1). Could there 
> be a legitimate leak here?

Given this description it certainly sounds like that. Can you present us the 
source code for an app that reproduces this leak?

--

-- 

  / daniel.haxx.se
Permalink | Reply | 3 comments |
headers
Patrick Scott | 2 Feb 2009 19:47
Picon
Favicon

Re: CURLMOPT_MAXCONNECTS

Attached is the source of 10-at-a-time.c modified to load all the urls
at the same time.

Patrick

On Mon, Feb 2, 2009 at 1:16 PM, Daniel Stenberg <daniel <at> haxx.se> wrote:
> On Mon, 2 Feb 2009, Patrick Scott wrote:
>
>> I just ran valgrind and found that all the non-cached connections were
>> leaked. I call curl_easy_cleanup for each handle and then curl_multi_cleanup
>> at the end. In curl_easy_cleanup, ConnectionDone is called for the
>> connection and lastconnect is set to connectindex (which is -1). Could there
>> be a legitimate leak here?
>
> Given this description it certainly sounds like that. Can you present us the
> source code for an app that reproduces this leak?
>
> --
>
>  / daniel.haxx.se
>
Attachment (test.cpp): text/x-c++src, 4490 bytes
Permalink | Reply | 2 comments |
headers
Senthil Raja Velu | 2 Feb 2009 20:25
Favicon

RE: CURL POST operation using read and write threads

Thanks for the pointers Dan!

-Senthil.

-----Original Message-----
From: curl-library-bounces <at> cool.haxx.se
[mailto:curl-library-bounces <at> cool.haxx.se] On Behalf Of Dan Fandrich
Sent: Friday, January 30, 2009 7:45 PM
To: curl-library <at> cool.haxx.se
Subject: Re: CURL POST operation using read and write threads

On Fri, Jan 30, 2009 at 07:02:23PM -0800, Senthil Raja Velu wrote:
> I am newbie to curl and trying to figure out how to use it with multi
threads.
> I need to perform a POST operation with XML content using a multi
threaded
> program. I need to perform the request operation in one thread and
read the
> response in another thread. I see the curl_easy_perform does it all on
one
> operation. But how do we make the write operation in one thread and
read
> operation in another. Any help is greatly appreciated.

Simple: you don't. libcurl, by definition, performs a single transfer
within 
a single thread.  If you need access to the results from another thread,
you can grant that access in a few ways. One is to simply download the
data
entirely into memory or disk and pass a pointer or file name to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 2 Feb 2009 22:29
Picon
Favicon
Gravatar

Re: CURLMOPT_MAXCONNECTS

On Mon, 2 Feb 2009, Patrick Scott wrote:

> Attached is the source of 10-at-a-time.c modified to load all the urls at 
> the same time.

Thanks!

Uhm, it is indeed a leak and I feel a bit embarrased it was this serious. I 
tightened the leak for the tests I've run by using this little fix:

--- lib/url.c   2 Feb 2009 16:19:23 -0000       1.785
+++ lib/url.c   2 Feb 2009 21:30:52 -0000
 <at>  <at>  -4804,8 +4804,12  <at>  <at> 
       state it is for re-using, so we're forced to close it. In a perfect world
       we can add code that keep track of if we really must close it here or not,
       but currently we have no such detail knowledge.
+
+     connectindex == -1 here means that the connection has no spot in the
+     connection cache and thus we must disconnect it here.
    */
-  if(data->set.reuse_forbid || conn->bits.close || premature) {
+  if(data->set.reuse_forbid || conn->bits.close || premature ||
+     (-1 == conn->connectindex)) {
      CURLcode res2 = Curl_disconnect(conn); /* close the connection */

      /* If we had an error already, make sure we return that one. But

I'll commit this to CVS just now, so if this does not heal the problem for you 
please let me know!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Patrick Scott | 2 Feb 2009 22:55
Picon
Favicon

Re: CURLMOPT_MAXCONNECTS

That is the exact same fix I have locally :)

Thanks!
Patrick

On Mon, Feb 2, 2009 at 4:29 PM, Daniel Stenberg <daniel <at> haxx.se> wrote:
> On Mon, 2 Feb 2009, Patrick Scott wrote:
>
>> Attached is the source of 10-at-a-time.c modified to load all the urls at
>> the same time.
>
> Thanks!
>
> Uhm, it is indeed a leak and I feel a bit embarrased it was this serious. I
> tightened the leak for the tests I've run by using this little fix:
>
> --- lib/url.c   2 Feb 2009 16:19:23 -0000       1.785
> +++ lib/url.c   2 Feb 2009 21:30:52 -0000
>  <at>  <at>  -4804,8 +4804,12  <at>  <at> 
>      state it is for re-using, so we're forced to close it. In a perfect
> world
>      we can add code that keep track of if we really must close it here or
> not,
>      but currently we have no such detail knowledge.
> +
> +     connectindex == -1 here means that the connection has no spot in the
> +     connection cache and thus we must disconnect it here.
>   */
> -  if(data->set.reuse_forbid || conn->bits.close || premature) {
> +  if(data->set.reuse_forbid || conn->bits.close || premature ||
(Continue reading)

Permalink | Reply | 0 comments |

Gmane