Результаты загрузки файлов в "IE не смогли открыть этот интернет-сайт"

Я не понимаю этого. Я смотрел повсюду, и, похоже, было много решений, но они не работают для меня. У меня есть приложение CGI:: Application, создающее электронную таблицу MS Excel со Spreadsheet:: WriteExcel. Это работало отлично в течение довольно долгого времени, пока наш живой сервер не имел аппаратного сбоя пару недель назад. Мы использовали отладку в качестве предлога для обновления до Windows Server 2008 (с 2003 года) и Apache 2.2.17 (с версии 2.2.11). Теперь я получаю спорадические (но слишком часто игнорируемые) жалобы от клиентов, получающих эту ошибку при попытке загрузить электронные таблицы:

Internet Explorer не может загрузить [url] с [сайта].
Internet Explorer не смог открыть этот интернет-сайт. Запрошенный сайт либо недоступен, либо не может быть найден. Повторите попытку позже.

Я пробовал IE 7-8 на XP, Vista и 7 и не смог воспроизвести эту ошибку локально. У пользователей, у которых есть проблема, есть это каждый раз, а не случайным образом. Все жалобы поступают от пользователей IE, в основном на IE8.

Прочитав пару сообщений об ошибке, я добавил заголовок -expires безрезультатно. (Не имея возможности проверить это непосредственно, мне пришлось реализовать исправление и подождать один день, чтобы посмотреть, перестают ли люди жаловаться ._.)

sub export_spreadsheet {
   my $self = shift;
   binmode STDOUT;

   my $str;
   open my $fh, '>', \$str;
   my $workbook = Spreadsheet::WriteExcel->new($fh);
   # words words words
   $workbook->close;
   close $fh;

   $self->header_add(-type => 'application/vnd.ms-excel',
                     -expires => '+1d',
                     -attachment => 'export.xls');
   return $str;
}

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

HTTP/1.1 200 OK
Date: Tue, 31 May 2011 22:23:17 GMT
Server: Apache/2.2.17 (Win32) mod_ssl/2.2.17 OpenSSL/0.9.8o mod_perl/2.0.4-dev Perl/v5.10.1
Expires: Wed, 01 Jun 2011 22:23:18 GMT
Content-Disposition: attachment; filename="export.xls"
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Content-Type: application/vnd.ms-excel
Content-Length: 18944
Accept-Ranges: none
Proxy-Connection: Keep-Alive

Текущее обходное решение, которое мы предоставляем клиентам (неспособным или не желающим переключиться на альтернативный браузер), связано с тем, что нужно переключиться на SSL, набрав сами https. Загрузка SSL отлично подходит для тех, кто попробовал это и вернулся к нам. Спекуляция: Может ли это быть прокси-сервером вниз по потоку с нашими заголовками? Может быть, поэтому он работает в SSL и ошибках в простом HTTP? (Обновление сервера было бы неудачным совпадением в этом случае.)

Ответ 1

Согласно http://support.microsoft.com/kb/316431 IE не может иметь дело с ситуациями, когда файл не кэшируется, но затем открывается каким-то внешним процессом, Это не тот же самый случай, но, как упоминал EricLaw в комментарии, он может иметь какое-то отношение к заголовку Vary и тому, что загрузка не имеет имени файла.

Я бы удалил этот заголовок и дал ему имя файла, и IE должен сохранить файл на диск, чтобы он мог быть открыт Excel.

Ответ 2

ЕСЛИ система в целом работает и что только загрузки происходят спорадически, тогда вы также можете попробовать указать имя файла динамическому имени.

Ответ 3

Недавно у нас был подобный случай, и после проверки целого группа of бесполезно answers на сайте MS, я наткнулся на интересный сообщение в блоге, которые проливают больше света на проблему, главным образом на заголовки, которые предотвращают кеширование (включая заголовок Vary, который закончил решение проблемы OP, +1).

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

В случае файлов Java/JSP (я уверен, что вы можете адаптировать тот же принцип к другим языкам), проблемы возникают, когда у вас есть что-то невинно выглядящее:

<%@ page contentType="text/html; charset="iso-8859-1" pageEncoding="iso-8859-1" errorPage="" language="java" session="true" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
[and so on]

то есть. возвращать карету как часть директив JSP вместо них, прежде чем вы создадите содержимое файла и отправить их в ответ, поскольку возврат каретки между такими строками - это пробел, который удаляет виртуальный ключ в IE деликатный механизм (обычные браузеры похоже, справляются с этим просто отлично). Если вы форматируете свой код следующим образом:

<%@ page contentType="text/html; charset="iso-8859-1" pageEncoding="iso-8859-1" errorPage="" language="java" session="true"
%><%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"
%>[and so on]

тогда вы должны быть в порядке. Я уверен, что большинство веб-разработчиков сталкивались с подобными проблемами, но в моем случае это было какое-то время, и мне пришлось несколько раз просмотреть JSP, прежде чем заметить, что одна строка не делала этого....