Hello friends of libCurl,
I discovered a busy waiting behaviour when libCurl establishes a tunnel
for SSL traffic through an HTTP Proxy (with HTTP CONNECT method).
My environment is as follows:
- Windows 2000 / QNX (problem occurs there too)
- libCurl 7.18.1, multi interface is used
- HTTP Proxy Server is simulated by a Python script which listens to a
accepts incoming connections but does not send any data back. That
situation when libCurl sent the HTTP CONNECT but does not receives any
(i.e. due to problems with physical layer).
Configuration of the easy handle runnuig inside a multi handle:
// Configuration of HTTP proxy
curl_easy_setopt( mHandle, CURLOPT_PROXYTYPE, CURLPROXY_HTTP ) );
curl_easy_setopt( mHandle, CURLOPT_PROXY, "aaa.bbb.ccc.ddd" ) ); // NIC
of local machine
curl_easy_setopt( mHandle, CURLOPT_PROXYPORT, 12345 ) ); // port which
listens the Python script on
curl_easy_setopt( mHandle, CURLOPT_PROXYUSERPWD, ":" ) ); // empty user
curl_easy_setopt( mHandle, CURLOPT_PROXYAUTH, CURLAUTH_BASIC ) );
// Configuration of URL, timeout
curl_easy_setopt( mHandle, CURLOPT_URL, "https://appserver" );
curl_easy_setopt( mHandle, CURLOPT_TIMEOUT, 600 ) // 600 seconds
The sequence of actions is as follows:
[MSG]@-282289109 (2236.0): About to connect() to proxy aaa.bbb.ccc.ddd
port 12345 (#0)
[MSG]@-282279812 (2236.0): Trying aaa.bbb.ccc.ddd...
[MSG]@-282279296 (2236.0): connected
[MSG]@-282227796 (2236.0): Connected to aaa.bbb.ccc.ddd
(aaa.bbb.ccc.ddd) port 12345 (#0)
[MSG]@-282227796 (2236.0): Establish HTTP proxy tunnel to appserver:443
[MSG]@-282227796 (2236.0): Proxy auth using Basic with user ''
[MSG]@-282227796 (2236.0): CONNECT appserver:443 HTTP/1.0
Proxy-Authorization: Basic Og==
select.c: before select()
select.c: after select() ret = 0
--> Now the Python script receives the HTTP CONNECT request,
but does not send any data back.
--> The application triggering libCurl gets the current file descriptors:
curl_multi_fdset( multiHandle, &fdread, &fdwrite, &fdexcep, &maxfd ) )
and selects on them:
rc = select( maxfd+1, &fdread, &fdwrite, &fdexcep, &timeout ); //
timeout = 1 second
After libCurl has send the HTTP CONNECT request, select() returns
with 1 (here: one file descriptor is ready for writing. That file
belongs to the socket to the HTTP Proxy / Python script on which the
CONNECT has been sent).
As select() returns immediately everytime with one file descriptor
ready for writing,
as long as the HTTP Proxy has not send any data back, the thread /
method in which context
libCurl is triggered, is executed again. Then it selects again,
with 1 file descriptor (the same) ready for writing and so on. That
results in a high
CPU usage until the configured timeout expired.
Currently I am wondering why the socket is writable for the time the
does not send any data back. With libCurl 7.16.3 that does not happen
(tested under QNX as Windows behaves differently in that scenrio with
7.16.3 and 7.18.1 ).
Any thoughts what might be the problem or were to look next ?
Maybe its an configuration issue ?
Has it something to do with the recently reported busy looping bug:
http://curl.haxx.se/mail/lib-2008-04/0513.html ? According to my
my problem differs from that one.
Received on 2008-05-06