cURL / Mailing Lists / curl-users / Single Mail

curl-users

Persistent connection problem

From: Andreas Rieke <andreas.rieke_at_isl.de>
Date: Sun, 14 Sep 2003 12:17:35 +0200

Hi,

I am using libcurl 7.10.7 on a redhat 7.2 machine within my C programs
with the easy interface to process requests with an HTTPS server.
Everything works well as long as I start a libcurl easy session with the
curl_easy_init call before doing a request.

However, I would like to use the keep-alive feature of HTTP/1.1 and
thus, I have changed my software in order to perform a single
curl_easy_init at program start (and a single cleanup at the end). In
this sitution, I see strange things when looking at the packets with
tcpdump.

cURL establishes a new connection with the SSL server, performs the SSL
handshake and then sends the request and receives the answer (in fact,
one can only see that packets are sent since everything is encrypted,
but my application works). As they should, neither cURL nor apache send
F (fin) or R (reset) packets. Since apache is (by default) configured to
kill persistent connections after 15 seconds, an F packet is sent by
apache after that time (and curl sends an ack for that). So far, so
good.

However, curl seems not to recognize that the connection is gone. When a
new request is started, cURL tries to use the old connection which it
has acknowledged to be finished a few seconds before. As apache sends a
reset for that immediately, cURL starts a new connection and performs
the requst without further problems.

You might think that this bug does not matter because the only problem
is that two more packets are exchanged, but this is not true. Imagine a
firewall with stateful inspection between cURL and apache, and you will
see that after the F packet from apache (and the ack for that) no more
data will be accepted on that connection (since it is in fact closed).
Thus, cURL will try to reuse the connection and wait until a timeout
occurs, and this takes much time.

Has anybody seen similar things? Is there any workaround or bugfix
available for this problem?

Thanks in advance,

Andreas

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2003-09-14