cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: make only connect, but not issue GET request

From: Pankaj Takawale <pankaj.takawale_at_gmail.com>
Date: Tue, 15 Mar 2011 09:43:17 -0400

I'm polling web server using curl.
Network trace shows me that - web server breaks the connection on prev
hit after sending response.
When I try to make next request, curl_easy_perform detects broken
connection, re-connects and make transfer.
Re-connection is expensive over here - around 300ms (TCP connection +
SSL handshake).

I would like to detect broken connection and re-connect only (NO
transfer) well before I make next request. This would mostly save
re-connection time at the time of next request.
Do you see any work-around to achieve same effect?

On Tue, Mar 15, 2011 at 4:18 AM, <curl-library-request_at_cool.haxx.se> wrote:
> Message: 3
> Date: Mon, 14 Mar 2011 22:07:34 +0100 (CET)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: make onlcurl-library_at_cool.haxx.seonly connect, but not
>        issue   GET request
> Message-ID: <alpine.DEB.2.00.1103142206220.1309_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Mon, 14 Mar 2011, Pankaj Takawale wrote:
>
>> OS Platform is linux 2.6.18
>> curl is 7.15.4
>
> That's a very old version, please consider upgrading!
>
>> I'm polling https server twice a sec. Server is breaking connection every
>> minute one to three times (no particular pattern timing wise) Is there any
>> way to tell curl to make only connection (but not issue http GET) with
>> server if connection is broken?
>
> No, libcurl has no such ability. After all, what would it do with the
> connection after just connecting to the server again? Seems rather pointless
> to me...
>
> --
>
>  / daniel.haxx.se
>
>
> ------------------------------

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-03-15