Interestingly yesterday i found a bug where libcurl keeps trying to send
data on a closed connection when i post a request through proxy
(This happens only through a proxy) and when i reuse the same connection
I use curl 7. 9.1.
This is a quick hand made patch

File: <File: > url.c Line :1014
static bool
ConnectionExists(struct SessionHandle *data,
                 struct connectdata *needle,
                 struct connectdata **usethis)
{
...

    else { /* The requested needle connection is using a proxy,
              is the checked one using the same? */
       if(check->bits.httpproxy &&
         strequal(needle->proxyhost, check->proxyhost) &&
         needle->port == check->port) {
 + bool dead = SocketIsDead(check->firstsocket);
 + if(dead) {
 + infof(data, "Connection %d through proxy seems to be dead!\n",
i);
 + Curl_disconnect(check); /* disconnect resources */
 + data->state.connects[i]=NULL; /* nothing here */
 + continue; /* try another one now */
 + }
        /* This is the same proxy connection, use it! */
        *usethis = check;
        return TRUE;
      }

File: http.c Line :937

      /* issue the request */
      data->info.request_size =
        add_buffer_send(conn->firstsocket, conn, req_buffer);
  + if(-1 == data->info.request_size){
  + #if defined(WIN32)
  + infof(data, "Error %d encountered in
add_buffer_send",GetLastError());
  + #else
  + infof(data, "Error encountered in add_buffer_send");
  + #endif
  + return CURLE_WRITE_ERROR;
  + }

Check if this helps

Regards
Bharath

Daniel Stenberg wrote:

On Wed, 27 Mar 2002, Rogerio Saran wrote:

I am writing a wrapper around libcurl (7.9.5) to make it suitable to be
called through libwww-perl (LWP). The goal is to replace the current LPW
https handler with a higher performance one.

Sounds like an interesting project.

[snip]

> POST /GRIPNET/gracgi.EXE HTTP/1.1^M
Host: bankline.itau.com.br^M
Pragma: no-cache^M
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*^M
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)^M
Content-Length: 91^M
Content-Type: application/x-www-form-urlencoded^M
^M
...post data...

>>>>> oh no!

* Closing connection #0

Do you happen to know why it decides that this connection needs to be
closed?

Organox::Protocol::LibCurl::request: Curl::easy::perform result 0
Organox::Protocol::LibCurl::request: request 8.773619
Organox::Protocol::LibCurl::request: read 26547 bytes

>>>>> the response code is "100 continue"...

Organox::Protocol::LibCurl::build_response: HTTP/1.1 100 Continue
Organox::Protocol::LibCurl::build_response: Date: Wed, 27 Mar 2002
13:58:56 GMT
Organox::Protocol::LibCurl::__ANON__: Date: Wed, 27 Mar 2002 13:58:56
GMT
Organox::Protocol::LibCurl::__ANON__: Server: Microsoft-IIS/4.0
Organox::Protocol::LibCurl::request: final 0.002665
LWP::Protocol::collect: read 26458 bytes

Anybody wonder why libcurl is closing the connection even after
receiving a
"continue" response code?

Yes, I wonder why.

AFAICR, the 100-response code just eats that and then awaits the next
"real"
header so it should close the connection because of this.

Are you sure it isn't the proxy or server that closes this connection?
Received on 2002-03-27