IE не выполняет перенаправление, выдает «Internet Explorer не может отобразить веб-страницу»

Question

У меня есть форма с несколькими полями.Когда вы отправляете форму, сервер отвечает перенаправлением (HTTP 302).

При отправке формы, если есть поле <input type=file>, IE не выполняет перенаправление, а вместо этого выдает ошибку: «Internet Explorer не может отобразить веб-страницу».

Если имеется поле no <input type=file>, оно следует за перенаправлением, как и ожидалось.

Ответ HTTP 302 точно одинаков в обоих случаях, отличается толькок отметке времени ответа.

Я испытываю это в IE8 и IE9.(Я не пробовал более низкие версии).Firefox, Chrome, Opera и Safari следуют за перенаправлением, как и ожидалось.

Примечания:

• Форма имеет атрибут enctype="multipart/form-data".
• Это происходит черезSSL
• Перенаправление не на другой протокол, хост или порт, чем URL-адрес, по которому форма отправляется или размещается.
• Когда я проверяю трафик HTTP с помощью Fiddler2 проблема исчезает и IE ведет себя.

Answer 1

Вопросу 3 года, но я сам недавно столкнулся с этой проблемой и нигде не нашел правильного ответа.Ответ, помеченный как принятый здесь, на самом деле ничего не отвечает.

Для меня было важно добавить следующий заголовок к ответу 302:

 Connection: close

Я перенаправил на другой сайт с полным URL-адресом, и, похоже, IE пытается оптимизироватьподключений путем отправки последующих запросов по тому же потоку TCP без повторного его открытия, но он недостаточно умен, чтобы выяснить, что сайт отличается без явной инструкции «Соединение» в заголовке.

Это происходит по крайней мере в IE10 и IE11, и ни у одного из других браузеров такой проблемы нет.

Answer 2

Перенаправление на частичный или полный URL (с хостом, протоколом и т. Д.)? Я видел множество примеров в PHP, где перенаправление с 302, в котором нет полного http://server.dom/path/to/file, будет игнорироваться или искажаться IE. В Rails это может быть разница между foo_path и foo_url в маршрутизаторе.

Answer 3

Просто добавьте к этому для тех, у кого такая же проблема:

IE кажется довольно строгим в том, как формируется команда header. Моя заявка боролась с:

header("location:http://www.test.co.uk/test/test.php");

или

header("location:test.php");

Но начал работать, когда команда была изменена на:

header("Location: http://www.test.co.uk/test/test.php");

Answer 4

Еще один совет для людей, испытывающих эту проблему:

В моем случае некоторые установки IE11 не перенаправляли должным образом, другие (даже те же точные версии IE). Когда это не работает, IE не определяет конец страницы перенаправления и начало следующей страницы .

Это проявляется в браузере как фрагмент HTML-кода конца страницы перенаправления, за которым непосредственно следует содержимое фактической страницы, которую необходимо было загрузить.

Если сжатие было включено, мы увидели бы конец страницы перенаправления, за которым следовал искаженный текст (сжатая версия следующей страницы):

Когда сжатие отключено , происходит то же самое, отображается конец страницы перенаправления и отображается следующая страница. Поскольку это обычный HTML, IE отображает его, и он выглядит так:

Очевидно, что IE не определяет, когда заканчивается страница перенаправления, и начинается следующая страница.

Мы запускали Python / Flask под IIS на сервере. У нас точно такие же версии IE, где один браузер будет иметь эту проблему, а другой нет. Мы тщательно сравнили все настройки, но не смогли воспроизвести проблему в работающем браузере или наоборот.

Я попытался обновить библиотеку Python (Werkzeug), которая выполняет фактическое перенаправление, я обновил wfastcgi.py, компонент, который интегрирует Python с IIS, обе эти вещи не имели значения.

Что я в итоге сделал:

Перенаправление с использованием полного URL работало во многих случаях. Поэтому мы убедились, что все наши перенаправления используют абсолютные URL-адреса, а не относительные.

После этого остались некоторые перенаправления, из-за которых у IE возникли проблемы с загрузкой. Оказалось, что у этих перенаправлений была дата в конце (в строке запроса). В конце я добавил фиктивный параметр строки запроса, и проблема исчезла.

Например:

Если исходный URL заканчивался /diary?targetday=2018-01-01, я бы изменил его на /diary?targetday=2018-01-01&test=1, чтобы он работал.

Надеюсь, это кому-нибудь поможет.