Agreed. If PASV returns success, but the connection fails, timing out is the only option, and it's annoying.
I admit I haven't played with FTP-aware firewalls since the mid 90s, but for a firewall to support active FTP at all, it must be sniffing or proxying all FTP command channel traffic. This was why I suggested looking at the result of "PASV". The usual case is "PASV works where PORT does not", of course. --Amanda On Wed, Sep 9, 2009 at 4:00 PM, Michal Zalewski <[email protected]> wrote: >> The bug is about a firewall forbidding the connection. Why the trick won't >> work? If I can't connect to the PASV port, I'd try PORT, even on successful >> PASV response. > > I was specifically referring to Amanda's suggestion, which was: > > "It should be fairly easy. Send the PASV command--if the server sends > back a failure result code, fall back on active FTP and send a PORT > command." > > ...we wouldn't be getting an error code, but a connect() timeout > instead. We could fall back at that point, but we just wasted anywhere > between 15 seconds and 4 minutes, depending on how aggressively we set > our timeouts... we would need to cache the outcome ("always use active > mode for this server"), at the very least. > > /mz > -- "Portability is generally the result of advance planning rather than trench warfare involving #ifdef" -- Henry Spencer (1992) --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
