Результаты загрузки файлов в " IE не удалось открыть этот интернет-сайт"
Я в недоумении для этого. Я просмотрел все, и, похоже, есть много решений, но они не работают для меня. У меня в CGI::Приложения Приложения, генерирующего в 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 ответов
согласно http://support.microsoft.com/kb/316431 IE не может иметь дело с некоторыми ситуациями, когда файл не кэшируется, но затем открывается каким-то внешним процессом. Это не тот же случай, но как EricLaw упоминалось в комментариях, это может что-то сделать с Vary
заголовок и тот факт, что загрузка не имеет имени файла.
Я бы удалил этот заголовок и дал ему имя файла, и IE должен иметь возможность сохранить файл на диск, чтобы он мог быть открыт Excel.
Если система в целом работает и что только загрузки спорадически не удается, то вы также можете попробовать дать имя файла динамическое имя.
недавно у нас был аналогичный случай, и после проверки весь кучу of бесполезно ответы на сайте 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, прежде чем заметить, что одна строка этого не делала....