Результаты загрузки файла в "IE не удалось открыть этот интернет-сайт" - PullRequest
12 голосов
/ 01 июня 2011

Я в растерянности из-за этого. Я просмотрел все, и кажется, что есть много решений, но они не работают для меня. У меня есть приложение 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? (Обновление сервера было бы неудачным совпадением в этом случае.)

Ответы [ 3 ]

8 голосов
/ 01 июня 2011

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

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

2 голосов
/ 01 июня 2011

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

1 голос
/ 22 марта 2013

Недавно у нас был похожий случай, и после проверки целого связки из бесполезных ответов вна сайте 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, прежде чем я заметил, что одна строка этого не делает ...

...