IE8 violates RFC959; breaks certain legacy applications using FTP via WININET.

I am supporting a number of machines running a client application that needs to connect to a FTP server, located at remote location. All these machines are running Windows XP SP3. Some of them have IE6 installed, others have IE7. Recently, some of them were upgraded to IE8. As a result, the application stopped working there. Upon investigation, that took me most of the weekend, I think I managed to track down the reason. It follows below.

The client application needs to connect to the FTP server, at address, let's say, 10.10.0.1:21, using passive mode. After receiving the PASV command from the client, the server returns the following response:

227 Entering Passive Mode (10, 10, 1, 1, 117, 58)

after which the connection breaks and the application returns an error. I managed to determine that the failing function is FtpOpenFile, and it fails with error code 12003 (ERROR_INTERNET_EXTENDED_ERROR). I am almost sure that the WININET code gets confused by the different destinations for the control and data connections (namely, 10.10.0.1 and 10.10.1.1) or refuses to pass the call due to security reasons maybe. However, the different destinations for the control and data connection is a perfectly valid technique, and it is used routinely for FTP load balansing purposes, for example. Therefore, by disabling this feature (knowingly or unknowingly) IE8 violates the established FTP standard. By the way, IE6 and IE7 both work well for me; my problem is only with IE8. And I feel more than little distressed in the light of the Microsoft plans for automatic upgrading to IE8. Should I disable Windows Update on all machines I administer, just to be safe?

Continue reading...