Hi --

We've been seeing some strangeness with HTTPS transfers running on
machines sitting behind NAT routers. If the NAT changes public
address while a transfer is ongoing, the libcurl app will spin
forever waiting for the transfer to complete. One behavior I have
seen is the Apache log showing the web hit timing out after the
server's timeout, but on the client the socket is still in the
ESTABLISHED state so the app thinks all is well.

(I can force this behavior at will by manually forcing my Linux NAT
router to drop and reestablish the DSL connection, resulting in a new
public IP address being assigned).

The bludgeon solution that I'm currently trying is to set
CURLOPT_TIMEOUT; this appears to work, but doesn't directly address
the problem. It also doesn't address the problem of long transfers
that could exceed whatever default timeouts we choose. I'm thinking
about adding a cancel-transfer-if-no-data-received-lately
functionality, but haven't gotten there yet.

Has anyone else run into this? Any recommendations? Perhaps there are
NAT settings that need to be tweaked ...

Thanks,
--bob
Received on 2007-06-02