curl / Mailing Lists / curl-library / Single Mail


Re: Proxied CURL socket closing prematurely

From: Neil Canham <>
Date: Tue, 24 Apr 2018 11:26:58 +0100

 Re-reading my post I realise it wasn't clear enough. It is the socket
that I'm writing the data to in my client application that we obtain from
Curl. It is also this same socket that is the source of the FIN that we
detect arriving at the proxy. The next time we try to write to the socket
on the client to send the next buffer of data, it can't be written to -
closed. When I have the same client application with a socket that I
didn't get from Curl this doesn't happen - we write and write until we are
done then we close the socket.

On 23 April 2018 at 08:26, Daniel Stenberg <> wrote:

> On Sat, 21 Apr 2018, Neil Canham wrote:
> use libcurl to perform the initial HTTP CONNECT and then continue to use
>> the resulting socket for the transfer as we did before.
>> This is mostly working very well, however we find that when transferring
>> more than around 65-70k bytes the tunnelled socket closes of its own
>> accord. Wireshark shows that the final packet sent has its FIN flag set.
>> There is more data to be sent, and our code has not closed the socket.
> Since you're then reading a socket that's totally outside of libcurl and
> its control and not even libcurl anymore at that point, this isn't a curl
> issue.
> Are you saying the FIN comes from the system that runs your application
> that only reads from the socket? And those reads (recv()s?) just suddenly
> stops and the kernel sends an (from the outside seemingly unmotivated) TCP
> FIN to the peer (which is the proxy)? That sounds mighty weird and I think
> it could indicate a problem at TCP level somewhere, either in the proxy or
> in the stack of your application's system. I don't have any easy tricks or
> debugging magic to fix this with. Roll up your sleaves and dig deeper. And
> wireshark more! =)
> --
> /
> -------------------------------------------------------------------
> Unsubscribe:
> Etiquette:

Received on 2018-04-24