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
socket and
  accepts incoming connections but does not send any data back. That
simulates the
  situation when libCurl sent the HTTP CONNECT but does not receives any
answer
  (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
/ passwd
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
Host: appserver:443
Proxy-Authorization: Basic Og==
Proxy-Connection: Keep-Alive
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
every time
    with 1 (here: one file descriptor is ready for writing. That file
descriptor
    belongs to the socket to the HTTP Proxy / Python script on which the
HTTP
    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,
select() returns
    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
HTTP proxy
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
understanding,
my problem differs from that one.

Best regards,

     Stefan
    
    
    
    
    
    
        
Received on 2008-05-06