curl-library

From: Axel Sauerh�fer <asauerhoefer_at_nero.com> Date: Fri, 19 Sep 2008 13:13:42 +0200 · > There looks to me like there's still a race condition in there. If a

-- 
  / daniel.haxx.se
------------------------------
Message: 2
Date: Thu, 18 Sep 2008 14:15:48 +0200 (CEST)
From: Daniel Stenberg <daniel_at_haxx.se>
Subject: Re: using libcurl for ipp
To: libcurl development <curl-library_at_cool.haxx.se>
Message-ID: <alpine.LRH.1.10.0809181414580.10702_at_yvahk3.pbagnpgbe.fr>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 9 Sep 2008, benoy m wrote:
> I was wondering if anybody has used libcurl for Internet Printing
Protocol. 
> If so can you point me in the right direction to get started.
IPP is "over HTTP" so I figure you can easily just tell libcurl to send the 
protocol data to the server!
-- 
  / daniel.haxx.se
------------------------------
Message: 3
Date: Thu, 18 Sep 2008 13:13:44 -0400
From: Wei Weng <wweng_at_acedsl.com>
Subject: Re: I need application describing curl multi interface
	APIs...
To: libcurl development <curl-library_at_cool.haxx.se>
Message-ID: <48D28C48.9040703_at_acedsl.com>
Content-Type: text/plain; charset=ISO-8859-1
haritha a wrote:
> Hi,
> 
> I need a link or example programs which describe the multi interface
> APIs...
> 
> Regards,
> Haritha.
Dear Haritha,
Have you looked at docs/examples/multi*.c?
There are quite a few samples that use multi interface.
Thanks
Wei
------------------------------
Message: 4
Date: Thu, 18 Sep 2008 15:01:57 -0700
From: Dan Fandrich <dan_at_coneharvesters.com>
Subject: Signal handling problem in libcurl
To: curl-library_at_cool.haxx.se
Message-ID: <20080918220156.GA6403_at_coneharvesters.com>
Content-Type: text/plain; charset=us-ascii
There's a problem with the way libcurl currently handles the SIGALRM signal.
It installs a handler for SIGALRM to force a synchronous DNS resolve to time
out after a specified time, which is the only way to abort such a resolve
in some cases. Just before the the DNS resolve takes place it initializes a
longjmp pointer so when the signal comes in the signal handler just does
a siglongjmp, control continues from that saved location and the function
returns an error code.
The problem is that all the following control flow executes effectively
inside the signal handler.  Not only is there a risk that libcurl could
call an async handler unsafe function (see signal(7)) during this time,
but it could call a user callback function that could call absolutely
anything.  In fact, siglongjmp() itself is not on the POSIX list of
async-safe functions, and that's all the libcurl signal handler calls!
The right approach is probably to find some way to interrupt the resolver
from within the signal handler and have it abort normally with an error
code (a flag set within the signal handler would tell if the abort was
due to timeout or not).  That would allow the flow of control to remain
outside the signal handler and avoid this problem. The question is: is
it possible to force a resolver to abort like this (maybe by sending
it another signal), and if so, is it portable?
>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved
------------------------------
Message: 5
Date: Thu, 18 Sep 2008 23:29:18 +0100
From: Jamie Lokier <jamie_at_shareable.org>
Subject: Re: Signal handling problem in libcurl
To: curl-library_at_cool.haxx.se
Message-ID: <20080918222918.GA29897_at_shareable.org>
Content-Type: text/plain; charset=us-ascii
Dan Fandrich wrote:
> The right approach is probably to find some way to interrupt the resolver
> from within the signal handler and have it abort normally with an error
> code (a flag set within the signal handler would tell if the abort was
> due to timeout or not).  That would allow the flow of control to remain
> outside the signal handler and avoid this problem. The question is: is
> it possible to force a resolver to abort like this (maybe by sending
> it another signal), and if so, is it portable?
The only way I can think of is to run the resolver in a child process,
with the result communicated by pipe, and kill the child process if
you don't want it any more.
-- Jamie
------------------------------
Message: 6
Date: Fri, 19 Sep 2008 00:46:06 +0200 (CEST)
From: Daniel Stenberg <daniel_at_haxx.se>
Subject: Re: SFTP fails (Failure when receiving data from the peer)
To: the curl tool <curl-users_at_cool.haxx.se>
Cc: libcurl hacking <curl-library_at_cool.haxx.se>
Message-ID: <alpine.LRH.1.10.0809190021050.22401_at_yvahk3.pbagnpgbe.fr>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
On Thu, 18 Sep 2008, hippocat_at_verizon.net wrote:
I'm cc'ing my reply to the curl-library list which really is more suitable
for 
this topic! Please take follow-ups on that list.
Your mail did confuse me. Here's a bunch of questions and comments...
> And finally:
>
>    bytesfromsocket = MIN((long)sizerequested, conn->data->set.buffer_size
?
>                          conn->data->set.buffer_size : BUFSIZE);
>
> if(conn->protocol & PROT_SFTP)
>      nread = Curl_sftp_recv(conn, num, buffertofill, bytesfromsocket);
>
> Ok, curl requesting buffer with magic number 16384 + ?head data?
Can you explain to me how it can ask for more than 16384 bytes with this
code?
As I read it, the code asks for up to 16384 bytes. Possibly less - but never
more.
> and it is always generating error LIBSSH2_ERROR_CHANNEL_PACKET_EXCEEDED
for 
> that specific server (looks like it sends extra data which is ?Spec says
we 
> MAY ignore bytes sent beyond? ? just legal, but not for curl).
If libssh2 returns an error libcurl will consider that to be an error. If
the 
case is fine by a protocol spec libssh2 should not return an error in the 
first place.
> Then data truncated and makes data out of sync with data len
How is that? libssh2 returns an error then isn't libcurl just bailing out?
And if not, how is it getting out of sync?
> curl getting crazy and connection dropped by sftp server.
How is "curl getting crazy" because of this?
> Simple fix is to reduce CURL_MAX_WRITE_SIZE and it works.
How come 16K is such a magic limit for the SSH2 code, do you know?
I disagree it being a fix though, it's just a work-around!
> How many bytes ? I believe it depends on server, but something like 16000 
> will work.
Hm, does this mean we can force the bug to happen if we instead bump the 
buffer size to something like 32K or so? I mean as a help to fix this 
"properly" in the libssh2 end?
I can consider adding the work-around for the SFTP case just to make libcurl
play better with existing libssh2 but I would prefer to make a real fix (as 
well).
> Or just disable data truncation in libssh2 which is also works.
But that will make libssh2 send more data than its windows allow, doesn't
it? 
Or did I misunderstand that check?
> I beleive there is better patch but I dont have time to dig cURL, so 
> probably developers could take care about this special case ?
I'll try!
-- 
  / daniel.haxx.se
------------------------------
Message: 7
Date: Thu, 18 Sep 2008 23:46:52 -0700
From: Dan Fandrich <dan_at_coneharvesters.com>
Subject: Re: Signal handling problem in libcurl
To: curl-library_at_cool.haxx.se
Message-ID: <20080919064651.GA9770_at_coneharvesters.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 18, 2008 at 11:29:18PM +0100, Jamie Lokier wrote:
> The only way I can think of is to run the resolver in a child process,
> with the result communicated by pipe, and kill the child process if
> you don't want it any more.
Good idea!  I'm a bit worried about actually doing this unconditionally
in libcurl, though.  A multi interface using program with a few hundred
handles open could all of a sudden see hundreds of processes being created
for this purpose. Mind you, a multi interface using program with a few
hundred handles open should be using c-ares, but creating processes within
libcurl could still have the potential of messing up an unsuspecting app.
>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved
------------------------------
Message: 8
Date: Fri, 19 Sep 2008 11:32:58 +0200
From: Axel Sauerh?fer <asauerhoefer_at_nero.com>
Subject: Detecting ssl connection errors in multi handle interface
To: <curl-library_at_cool.haxx.se>
Message-ID: <001a01c91a3a$b412b500$1c381f00$@com>
Content-Type: text/plain;	charset="iso-8859-1"
How can I detect a ssl connection error ? I am using the multi handle
interface.
I tried to check the return value from curl_multi_perform but without
success. 
Always I get the following 2 return codes:
* CURLM_CALL_MULTI_PERFORM 
* CURLM_OK
Unfortunately my program is running into endless loop ;(
Can somebody give me a hint? 
This is my first day working with the libcurl, so I am a real newbie. Please
consider me for my questions.
Many thanks,
axel
--
------------------------------
Message: 9
Date: Fri, 19 Sep 2008 11:40:25 +0200 (CEST)
From: Daniel Stenberg <daniel_at_haxx.se>
Subject: Re: Detecting ssl connection errors in multi handle interface
To: libcurl development <curl-library_at_cool.haxx.se>
Message-ID: <alpine.LRH.1.10.0809191138380.8397_at_yvahk3.pbagnpgbe.fr>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On Fri, 19 Sep 2008, Axel Sauerh?fer wrote:
> How can I detect a ssl connection error ? I am using the multi handle 
> interface. I tried to check the return value from curl_multi_perform but 
> without success.
Allow me to quote http://curl.haxx.se/libcurl/c/libcurl-multi.html
   curl_multi_perform(3) stores the number of still running transfers in one
of
   its input arguments, and by reading that you can figure out when all the
   transfers in the multi handles are done. 'done' does not mean successful.
   One or more of the transfers may have failed. Tracking when this number
   changes, you know when one or more transfers are done.
   To get information about completed transfers, to figure out success or
not
   and similar, curl_multi_info_read(3) should be called. It can return a
message
   about a current or previous transfer. Repeated invokes of the function
get
   more messages until the message queue is empty. The information you
receive
   there includes an easy handle pointer which you may use to identify which
   easy handle the information regards.
We make a serious effort to create accurate docs for libcurl, please try 
reading them first!
-- 
  / daniel.haxx.se
------------------------------
_______________________________________________
curl-library mailing list
curl-library_at_cool.haxx.se
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-library
End of curl-library Digest, Vol 37, Issue 35
********************************************