wininet из IE 11 случайным образом возвращает ошибку 12003 для большинства функций FTP

У нас есть фрагмент кода для загрузки/выгрузки и списка файлов на ftp-сервере. Он использует WinInet для обработки команд FTP. Работает нормально уже несколько лет. Однако в Windows 8.1 и в Windows 7 с IE 11 один и тот же код иногда возвращает ошибку 12003. В логах ftp-сервера ошибок нет.

Простая функция используется для проверки наличия ошибок в FTP-ответе.

bool IsLastErrorReallyAnError()
{
 int err = GetLastError();

 bool isError = true;

 if (err == ERROR_INTERNET_EXTENDED_ERROR)
 {
     isError = false;
     DWORD error, size = 0;
    ::InternetGetLastResponseInfo(&error, NULL, &size);
    std::vector<wchar_t> response(size+1);
    ::InternetGetLastResponseInfo(&error, &response[0], &size);

    utils::trace("Backup", "Checking FTP respose", &response[0]);

    std::vector<std::wstring> lines;
    boost::split(lines, std::wstring(&response[0]), boost::is_any_of(L"\n"));

    for (auto it = lines.cbegin(); it != lines.cend(); ++it)
    {
        // If some response starts with 5хх then it is real error
        if (boost::starts_with(*it,L"5"))
        {
            utils::trace("Backup", "Real FTP error", &((*it)[0]));
            isError = true;
            break;
        }
    }

    if (!isError)
    {
        utils::trace("Backup", "Checking FTP respose ", L"false error!");
    }
 }

 return isError;
}

И в логах нашей программы получаем

05:56:43.680    0x21c   ERR CFtpFileSystem  CFtpFileSystem::TryOpenBinaryFile: FtpOpenFileW error 12003
05:56:43.680    0x21c   INF Backup  Checking FTP respose: 226 Transfer OK
200 Type set to I

05:56:43.680    0x21c   INF Backup  Checking FTP respose : false error!

В журналах FTP-сервера (у него другой часовой пояс):

(000445)30.10.2013 16:56:23 - (not logged in) (10.16.83.3)> Connected, sending welcome message...
(000445)30.10.2013 16:56:23 - (not logged in) (10.16.83.3)> 220-FileZilla Server version 0.9.41 beta
(000445)30.10.2013 16:56:23 - (not logged in) (10.16.83.3)> 220-written by Tim Kosse ([email protected])
(000445)30.10.2013 16:56:23 - (not logged in) (10.16.83.3)> 220 Please visit http://sourceforge.net/projects/filezilla/
(000445)30.10.2013 16:56:29 - (not logged in) (10.16.83.3)> USER test
(000445)30.10.2013 16:56:29 - (not logged in) (10.16.83.3)> 331 Password required for test
(000445)30.10.2013 16:56:35 - (not logged in) (10.16.83.3)> PASS ****
(000445)30.10.2013 16:56:35 - test (10.16.83.3)> 230 Logged on
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> TYPE I
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> 200 Type set to I
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> PASV
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> 227 Entering Passive Mode (10,16,82,191,238,169)
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> STOR /srv-test/0f0c04cc-c323-4bb6-a814-696fbbd695c3/527101B9/ab42ed5a-7df0-4421-a03c-d9f75891dcbf
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> 150 Connection accepted
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> 226 Transfer OK
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> TYPE I
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> 200 Type set to I
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> PASV
(000445)30.10.2013 16:56:43 - test (10.16.83.3)> 227 Entering Passive Mode (10,16,82,191,238,170)
(000445)30.10.2013 16:56:56 - test (10.16.83.3)> disconnected.

Любые идеи, как настроить версию wininet, которая поставляется с IE11, чтобы избавиться от таких ошибок?


person fav    schedule 30.10.2013    source источник


Ответы (2)


К сожалению, это не проблема в вашем коде.

Это один из немногих случаев, когда вы на самом деле столкнулись с совершенно новой, но серьезной проблемой в обновленной WinInet, включенной в только что выпущенный IE 11. Это сломает большинство FTP-приложений, использующих классы Microsoft FTP для пользователей Win 7/8, которые обновляются. . Я рекомендую вам добавить себя в этот отчет об ошибке: https://connect.microsoft.com/IE/feedback/details/808279/ftpopenfile-and-internetwritefile-broken-changed-in-ie11, чтобы, как мы надеемся, придать Microsoft некоторую актуальность.

Подробнее

Основная проблема заключается в любом FTP-взаимодействии, когда WinInet зависит от конкретных ответов сервера. Он будет работать ПЕРВЫЙ раз в сеансе FTP, но после этого WinInet всегда отстает от одного ответа, поэтому никогда не видит правильных кодов ответов, необходимых для обработки последующих запросов.

Пример

Режим PASV STOR требует, чтобы WinInet анализировала ответ сервера для открытого порта данных. При второй загрузке произойдет сбой, если используется FtpOpenFile() (хотя FtpPutFile, похоже, работает и, возможно, в режиме PORT).

Связанные проблемы

Есть также сообщения о сбоях не только самого первого FtpRename, потому что после фрагмента RNFR WinInet ожидает определенного ответа перед отправкой фрагмента RNTO. Когда WinInet отстает, он никогда не увидит ПРЕДЫДУЩИЙ код ответа сервера, никогда не увидит необходимый код ответа сервера, которого он ожидает (хотя трассировка подтверждает, что сервер отправил его).

Как воспроизвести

Это можно наблюдать, используя InternetGetLastResponseInfo() после каждого вызова FTP API. После первой загрузки PASV с использованием FtpOpenFile() или первого переименования все последующие вызовы API FTP будут отображать ответ сервера на ПРЕДЫДУЩИЙ вызов API FTP.

(PS: я думал, что указал на эту ошибку вчера - нет смысла пытаться "исправить" свой собственный код, когда проблема в другом месте. Но почему-то информация исчезает на следующий день. Надеюсь, люди найдут информацию на других сайтах, используя Google.)

person Andy Schmidt    schedule 23.11.2013

Я решил эту проблему, динамически загружая старую версию DLL, которую я нашел в папке SxS.

person Luiz Felipe    schedule 11.02.2014