On Fri, Jun 01, 2007 at 10:36:26PM -0500, Robert Olson wrote:
> 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.

The app has no reason to think otherwise in this case.

> 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.

You mean like the CURLOPT_LOW_SPEED_LIMIT option?
>
> Has anyone else run into this? Any recommendations? Perhaps there are
> NAT settings that need to be tweaked ...

Yes, which is what that option is for. You could probably force any open
TCP connections to be dropped when the public external address change
by sending a RST or something, but that would probably take some
scripting.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved