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

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

Internet Explorer не может загрузить [url] с [site].
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? (В этом случае обновление сервера было бы неудачным совпадением.)


person wes    schedule 31.05.2011    source источник
comment
Вы пробовали Fiddler проверять заголовки в обоих направлениях? Кроме того, какие ошибки возникают в других браузерах? Я часто нахожу, что Firefox или Chrome могут выдать гораздо более подробное сообщение об ошибке, которое устраняет проблему, о которой IE не сообщает вам!   -  person Russ Clarke    schedule 01.06.2011
comment
Эти заголовки взяты из Fiddler. Отличный маленький инструмент. У Firefox и Chrome нет проблем, и у пользователей, у которых возникла проблема, ее нет в других браузерах.   -  person wes    schedule 01.06.2011
comment
Вероятно, вам не следует отправлять заголовок VARY, так как это не делает ничего полезного в вашем сценарии и не позволит определенным версиям IE (например, IE8) кэшировать файл. Это, в свою очередь, может прервать загрузку, см., Например, blogs.msdn.com/b/ieinternals/archive/2009/10/03/   -  person EricLaw    schedule 01.06.2011
comment
Я пытаюсь понять, откуда берется заголовок Vary, так как сам никогда его не настраивал. Я предполагаю, что это делает Apache, но не могу найти где.   -  person wes    schedule 02.06.2011


Ответы (3)


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

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

person mpeters    schedule 01.06.2011
comment
Я пытаюсь отследить, откуда берется заголовок Vary. Я предполагаю, что Apache добавит его где-то в будущем. Не могли бы вы пояснить, что вы подразумеваете под загрузкой без имени файла? Я указываю имя файла в заголовке Content-Disposition. Есть ли еще что-нибудь, что я должен проверить? - person wes; 02.06.2011
comment
Я добавил метку времени к имени файла и ввел правило Apache для удаления заголовка Vary. Пользователи, у которых возникла проблема, сообщают, что теперь она работает. Для потомков директива Apache, которую я использовал: SetEnvIfNoCase Request_URI <url> no-gzip dont-vary - person wes; 02.06.2011

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

person r0ast3d    schedule 31.05.2011

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

person Amos M. Carpenter    schedule 22.03.2013