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! =)

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html