cURL / Mailing Lists / curl-users / Single Mail


Fwd: Re: keep-alive HTTP session

From: shlomit lisser <>
Date: Thu, 16 Jan 2003 22:01:20 +0200

The message was inserted in the wrong place, I'm trying again...

>Date: Thu, 16 Jan 2003 15:44:21 +0200
>From: Shlomit Lisser <>
>Subject: Re: keep-alive HTTP session
>What I meant, regarding the second page is that the first page is a login
>and since the connection is being closed, the second requests is accepted
>by the web server as a second login request and is being refused,
>what I can't figure out yet is how then a normal IE works, where you
>get the data with no problem, if indeed the connection is being closed
>by the web server?
>Also regarding the post/get issue. If a user sends tow URLs it
>should be fairly easy to distinguish a POST from GET request,
>something like -
>curl -o tmp.tmp --cacert ..... -d gfdgfdgfd !first_url ?another_url
>the first URL is a post request and the second is of course a get request.
>It looks like a small change that could be very handy. Just an idea...
>On Thu, 16 Jan 2003, shlomit lisser wrote:
> > ok, after some reading, sending the keep-alive header is really optional
> > and it will not work if the appropriate token is not being sent.
>Right, HTTP 1.1 does persistent connections by default if nothing else is
>told. And curl doesn't disconnect anything on purpose unless told so.
> > However according to your reply if I put two consecutive URLs in a command
> > line (both from the same site) cURL will use the same connection, right?
>Yes, if the server permits it.
> > well that is what I'm doing, I'm sending a login request (post) to a
> secure
> > site and then a link inside the site that should retrieve some data,
> and it
> > looks that the connection is being closed after the first page is being
> > received ( I'm getting a 'Closing connection #0'line in cURL output)
>Many SSL-enabled sites work that way. Curl really can't do anything if the
>server decides to close the connection, it can only obey and do its best.
> > and opened again re-using the SSL session id.
>Re-using the SSL session id is at least a performance gain compared to both a
>new connection AND a new session id.
> > The second page received specify that the user already logged in, which
> > coincide with the above.
>I don't follow you here.
> > Also the second url should be a get request and it is sent as a post (due
> > to the first request I guess).
>curl has no ability to first POST and then GET using one single command line.

This SF.NET email is sponsored by:
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Received on 2003-01-16