Basil Su | 1 Dec 09:33 2009
Picon

help--why didn't CONNECTIONTIMEOUT work? (curl-7.19.5)

HI ALL,
   i use curl-7.19.5
   i call the function like that curl_easy_setopt(_curl,CURLOPT_CONNECTTIMEOUT,(long)5) because i don't want to wait for a long time. but i fond it didn't work. it also stay stuck for almost 3 minutes just like it act without using this funciton.
   why didn't it work? and how could i make it not stay stuck for such a long time?

thanks
Basil 
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Daniel Stenberg | 1 Dec 10:26 2009
Picon

Re: help--why didn't CONNECTIONTIMEOUT work? (curl-7.19.5)

On Tue, 1 Dec 2009, Basil Su wrote:

>   i call the function like that
> curl_easy_setopt(_curl,CURLOPT_CONNECTTIMEOUT,(long)5) because i don't want

You already asked this and we haven't had time to reply. Please give us some 
time before you repeat your question.

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Klaus Darilion | 1 Dec 12:49 2009
Picon

new project file and README for Visual Studio 2005

Hi!

Attached is an extended version of the Visual Studio 2005 project file 
(lib/libcurl.vcproj).

The current project file has the following limitations:
- builds ony static LIBs which depends on Visual C Runtime DLL
- only one platform (win32)
- uses hard-coded output directories and names - thus cumbersome
   to extend

The attached version uses the Visual Studio Macros (e.g. $(OutDir)) 
instead of hard coded destinations, thus it is much more easy to add new 
targets/platforms. The attached version builds:
- static LIBs which depend on Visual C Runtime DLL (like current
   project file)
- static LIBs which do not depend on Visual C Runtime DLL
- above targets for win32 and x64 platform

The libraries will be placed into the following directories:
\
  lib
     \-Debug
     \-Debug_noVCRTdll
     \-Release
     \-Release_noVCRTdll
     \-x64
          \-Debug
          \-Debug_noVCRTdll
          \-Release
          \-Release_noVCRTdll

Attached is also a READM file (which is also part of the project and 
thus should be put into lib/ too) which describes the build targets and 
how to add new targets.

It would be great if you integrate this new project file and its README.

thanks
Klaus

Attachment (libcurl.vcproj): application/xml, 32 KiB
Libcurl includes a project file for Visual Studio. This project file resides at 
lib/libcurl.vcproj and was created with Visual Studio 2005. Thus, you should be 
able to use it with Visual Studio 2005 and newer version, which will 
automatically convert it into newer formats.

This project file supports 4 targets for 2 different platforms.

Platforms:
 - Win32 (x86 32 bit)
 - x64 (64 bit)

Targets:
- Release: Static Release Library with dependency on the Visual C Runtime DLL
- Release_noVCRTdll: Static Release Library without dependency on the Visual C 
                     Runtime DLL (VC Runtime will be statically linked)
- Debug: Static Debug Library with dependency on the Visual C Runtime DLL
- Debug_noVCRTdll: Static Debug Library without dependency on the Visual C 
                   Runtime DLL (VC Runtime will be statically linked)

The libraries will be placed into the following directories:
\
 lib
    \-Debug
    \-Debug_noVCRTdll
    \-Release
    \-Release_noVCRTdll
    \-x64
         \-Debug
         \-Debug_noVCRTdll
         \-Release
         \-Release_noVCRTdll

You can easily modify the targets or create a new target. For example you want 
to build static libraries without dependency on VCRT dll and without LDAP 
support (it is a good practice to create a new target instead of changing the 
default ones):
1. Build -> Configuration Manager
2. Active Configuration --> Choose <New...>
   Name: for exmaple "Debug_noVCRTdll_NOLDAP"
   Copy Settings from: Debug_noVCRTdll
   (create new project configurations) --> OK --> Close
3. Project --> Properties
   (select the new Debug_noVCRTdll_NOLDAP project if it is not already selected)
   Platform: select "all platforms"
   C/C++ --> Preprocessor --> Preprocessor Definitions: add CURL_DISABLE_LDAP
4. Repeat step 2 and 3 for a Release version without LDAP support
5. Build all the available targets for all platforms:
   Build --> Batch Build --> Select All --> Rebuild

Other targets, e.g. DLL instead of static libraries (Poject -> Properties -> 
Configuration Properties: General -> Configuration Type: Dynamic Library (dll)) 
can be added in similar way.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Daniel Stenberg | 1 Dec 13:05 2009
Picon

Re: [PATCH] Expect: 100-continue set by application

On Mon, 30 Nov 2009, Martin Storsjö wrote:

> If the Expect: 100-continue header has been set by the application through 
> curl_easy_setopt with CURLOPT_HTTPHEADER, the library should set 
> data->state.expect100header accordingly - the current code (in 7.19.7 at 
> least) doesn't handle this properly. The two attached patches fixes this.

Thanks, applied!

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Klaus Darilion | 1 Dec 13:08 2009
Picon

Re: help--why didn't CONNECTIONTIMEOUT work? (curl-7.19.5)

Basil Su wrote:
> HI ALL,
>    i use curl-7.19.5
>    i call the function like that 
> curl_easy_setopt(_curl,CURLOPT_CONNECTTIMEOUT,(long)5) because i don't 
> want to wait for a long time. but i fond it didn't work. it also stay 

Why does your function stuck? What is the cause for the hanging?
  - no DNS response?
  - no TCP connect?
  - no HTTP response?

For all these kinds of problems there are different timeout options (see 
man curl_easy_setopt)

klaus

> stuck for almost 3 minutes just like it act without using this funciton.
>    why didn't it work? and how could i make it not stay stuck for such a 
> long time?
> 
> thanks
> Basil 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette:  http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

L S | 1 Dec 13:15 2009
Picon

RE: Libcurl stops when sending lots of https messages


Sorry for the late reply!

>> Curl_socket_ready do return the correct value. Since openSSL want us to
>> write information to the socket after a SSL_ERROR_WANT_WRITE error code it
>> seems reasonable that Curl_socket_ready should return 2 (CURL_CSELECT_OUT).
>> But Curl_readwrite only calls the recieve function if we have a readable
>> socket. And therein lies the fault.
>
> Exactly.
>
> We need to separate what to wait for and what to do when the waited-for action
> occurs since in this case the socket gets writable and we should still call
> the read function to take care of it.
>
> When thinking about it, I think we also have the same error for SSH although
> we may not yet have found a case where it becomes visible.
>
>> Insted of using the return value from the Curl_socket_ready (which isn't a
>> good measure of determine what to do since both SSL_write and SSL_read might
>> use both readable and writeable sockets during a renegotiation ) we need
>> some other way of knowing what we are doing. But I don't really see an easy
>> way of doing this.
>
> Curl_socket_ready() is a rather low-level function that needs to stay working
> exactly like it does.
>
> I suggest we introduce a new internal struct member or two that allows the
> protocol-specific parts to set a forced action to assume, and the
> Curl_readwrite() function would then check that field first before it assumes
> that the event implies a specific action.
>
> It could work in a way similar to this (throwing out a suggestion):
>
> Index: lib/transfer.c
> ===================================================================
> RCS file: /cvsroot/curl/curl/lib/transfer.c,v
> retrieving revision 1.442
> diff -u -r1.442 transfer.c
> --- lib/transfer.c 12 Nov 2009 14:36:34 -0000 1.442
> +++ lib/transfer.c 15 Nov 2009 14:28:12 -0000
>  <at>  <at>  -1649,6 +1649,7  <at>  <at> 
> curl_socket_t fd_read;
> curl_socket_t fd_write;
> int select_res = conn->cselect_bits;
> + int act_data; /* how to act on the data */
>
> conn->cselect_bits = 0;
>
>  <at>  <at>  -1675,21 +1676,24  <at>  <at> 
> return CURLE_SEND_ERROR;
> }
>
> - /* We go ahead and do a read if we have a readable socket or if
> - the stream was rewound (in which case we have data in a
> - buffer) */
> + /* We go ahead and do a read if we have a readable socket or if the stream
> + was rewound (in which case we have data in a buffer) */
> if((k->keepon & KEEP_RECV) &&
> - ((select_res & CURL_CSELECT_IN) || conn->bits.stream_was_rewound)) {
> + ((select_res & CURL_CSELECT_IN) || conn->bits.stream_was_rewound))
> + act_data |= (conn->forcewrite?KEEP_SEND:KEEP_RECV);
>
> + /* If we still have writing to do, we check if we have a writable socket. */
> + if((k->keepon & KEEP_SEND) && (select_res & CURL_CSELECT_OUT))
> + act_data |= (conn->forceread?KEEP_RECV:KEEP_SEND);
> +
> + if(act_data & KEEP_RECV) {
> result = readwrite_data(data, conn, k, &didwhat, done);
> if(result || *done)
> return result;
> }
>
> - /* If we still have writing to do, we check if we have a writable socket. */
> - if((k->keepon & KEEP_SEND) && (select_res & CURL_CSELECT_OUT)) {
> + if(act_data & KEEP_SEND) {
> /* write */
> -
> result = readwrite_upload(data, conn, k, &didwhat);
> if(result)
> return result;
>
> It shouldn't be too hard to adapt the SSL stuff to use this concept methinks.
> What you others think?

Well to me it seems like a possible solution. I will try it out as soon as I can.
I't doesn't seem all that hard to make it work.

>
>> One way ( but a quite ugly way I would say ) of solving the problem is to
>> solve the problem in the Curl_ossl_recv function by creating a loop until we
>> don't have a SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ error code ( or
>> until things times out ).
>
> We're already working hard to decrease the amount of blocking places within
> the code and I think adding new blocks without very good reasons is a bad
> idea. I much rather prefer we go the route I suggest above and polish it to
> work...

Well. I also prefer to cure the disease rather than remove the symtoms. I will try your 
fix and return the results to you in a couple of days.

>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
 		 	   		  
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Daniel Stenberg | 1 Dec 13:23 2009
Picon

Re: [PATCH/RFC] Adding Expect: 100-continue if post size is unknown

On Mon, 30 Nov 2009, Martin Storsjö wrote:

> If the size of the post data isn't yet known when starting the HTTP POST 
> request (i.e. when using chunked transfer encoding), the variable postsize 
> is 0 at line 1480 (in 7.19.7) in lib/http.c. With the current if statement 
> at that line, no Expect: 100-continue header is emitted under that 
> condition, even if the post data can be potentially huge.
>
> The attached patch is a sample of how this could be fixed, but I'm not 
> totally sure if this is the right approach. Would it perhaps be better to 
> make a distinction between actual size 0 and size unknown earlier in the 
> function?

I think I agree with you that appending the header is a good idea for the case 
when we don't know the size at all, but we must make a better distinction 
between unknown and zero since the suggested patch will lead to badness 
otherwise (visualized by the failure of test 175 to start with).

We use the specific case size 0 in a few circumstances for the first request 
in a multi-pass authentication (when we know the request won't be accepted but 
we expect a challenge response) and when we send zero bytes there's really no 
point in an Expect: header.

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Oran Agra | 1 Dec 13:33 2009
Picon

using WSAEventSelect with curl multi

Hi all,
I'm trying to use cURL multi on Windows Mobile.
Both easy and multi work well in blocking mode.

I'm trying to create a worker thread that can handle multiple transfers, and receive commends (like quit)
from other threads.

I've started with portions of the fopen.c sample that comes with curl, which uses curl_multi_fdset,
select, and then curl_multi_perform.

I figured I need to replace the curl_multi_fdset+select with a WaitForMultipleObjects, and use
WSAEventSelect to associate the socket with an event.

I thought I need to use curl_multi_setopt with CURLMOPT_SOCKETFUNCTION and maybe also with
CURLMOPT_TIMERFUNCTION, the first of which (according to my understanding should give me a socket
handle after the socket is created so that I can call WSAEventSelect).

I soon discovered that the CURLMOPT_SOCKETFUNCTION callback isn't called at all when using
curl_multi_perform, and searching in the samples I saw the only samples that use this callback are using
curl_multi_socket_all instead (a deprecated function).

I've tried using curl_multi_socket_all instead of curl_multi_perform, and my callback started to
happen, but later when I do WaitForMultipleObjects or WSAWaitForMultipleEvents it never goes out from
that call.
Btw, the call to WSAEventSelect returned with success.

So my questions are:

What am I doing wrong?

Did anyone ever managed to use curl multi with WSAEventSelect and WaitForMultipleObjects?

Is there a difference approach that I should use to get a thread that handles multiple connections, and
receives signals from other threads (on Windows)?

If there a sample code that can show me how to do this?

Thanks.
	Oran.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Daniel Stenberg | 1 Dec 13:58 2009
Picon

Re: using WSAEventSelect with curl multi

On Tue, 1 Dec 2009, Oran Agra wrote:

> I'm trying to use cURL multi on Windows Mobile.
> Both easy and multi work well in blocking mode.

The multi interface is not blocking...

This said: I don't know windows (mobile) details so please bear with me. I do 
however know a bit about the libcurl internals.

> I'm trying to create a worker thread that can handle multiple transfers, and 
> receive commends (like quit) from other threads.
>
> I've started with portions of the fopen.c sample that comes with curl, which 
> uses curl_multi_fdset, select, and then curl_multi_perform.
>
> I figured I need to replace the curl_multi_fdset+select with a 
> WaitForMultipleObjects, and use WSAEventSelect to associate the socket with 
> an event.

Why? Oh, is that because you only can select() on sockets in windows and you 
want to wait for that quit command using some other means?

Isn't WaitForMultipleObjects() however just a different select call so that it 
can wait for a number of sockets and some other file handles?

> I thought I need to use curl_multi_setopt with CURLMOPT_SOCKETFUNCTION and 
> maybe also with CURLMOPT_TIMERFUNCTION, the first of which (according to my 
> understanding should give me a socket handle after the socket is created so 
> that I can call WSAEventSelect).

Yes, you can set those but if you want the "raw" sockets you must use the 
curl_multi_socket_action() function instead of curl_multi_perform().

> I soon discovered that the CURLMOPT_SOCKETFUNCTION callback isn't called at 
> all when using curl_multi_perform, and searching in the samples I saw the 
> only samples that use this callback are using curl_multi_socket_all instead 
> (a deprecated function).

Two flaws on our behalf: 1) we should document that CURLMOPT_SOCKETFUNCTION is 
for the multi_socket API and 2) we should fix the examples to not use 
deprecated functions.

(I'll appreciate patches!)

> I've tried using curl_multi_socket_all instead of curl_multi_perform, and my 
> callback started to happen, but later when I do WaitForMultipleObjects or 
> WSAWaitForMultipleEvents it never goes out from that call.

So do they wait for the sockets the correct way? If so, why don't they return? 
Don't the socket(s) get any action? If they do, isn't that a sign you don't 
wait for them the correct way? If they don't, isn't that a sign something is 
seriously wrong?

> Btw, the call to WSAEventSelect returned with success.

I don't understand the difference or the importance with 
WSAWaitForMultipleEvents and WSAEventSelect so I'm afraid those subtleties get 
lost for me.

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Martin Storsjö | 1 Dec 14:00 2009

Re: [PATCH/RFC] Adding Expect: 100-continue if post size is unknown

On Tue, 1 Dec 2009, Daniel Stenberg wrote:

> I think I agree with you that appending the header is a good idea for the case
> when we don't know the size at all, but we must make a better distinction
> between unknown and zero since the suggested patch will lead to badness
> otherwise (visualized by the failure of test 175 to start with).
> 
> We use the specific case size 0 in a few circumstances for the first request
> in a multi-pass authentication (when we know the request won't be accepted but
> we expect a challenge response) and when we send zero bytes there's really no
> point in an Expect: header.

That's what I expected. Would this be a better solution, by setting it to 
-1 if it's unknown? (This is completely untested, but it's easier to show 
what I'm trying to say using a patch instead of trying to describe it 
verbally.)

// Martin
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Gmane