Проблемы с доставкой файлов PDF в IIS 7.5

Question

Это очень странная проблема - любые мысли / помощь / подсказки будут с благодарностью.

Наше веб-приложение передает файлы PDF в браузер, используя следующий код

byte [] fileBytes = GetTheFileBytes();
string contentType = "application/pdf";

context.Response.Clear();
context.Response.ClearHeaders();
context.Response.ContentType = contentType;
context.Response.AddHeader("Content-Length", fileBytes.Length.ToString());
context.Response.AddHeader("Content-Type", contentType);

MemoryStream outputStream = new MemoryStream(fileBytes);
outputStream.WriteTo(context.Response.OutputStream);
context.Response.Flush();

Это выглядит довольно безобидно и прекрасно работает в IIS 6 и IIS 7: если у пользователя установлен плагин PDF (Adobe или Foxit и т. Д.), То PDF отображается в браузере.

Однако в IIS 7.5 (Windows 7 и Win 2008 R2) плагин Foxit зависает в IE, а плагин Adobe - в IE и FF. т.е. если я введу

http://iis70Host/application/getPDF.aspx все хорошо, но http://iis75Host/application/getPDF.aspx в том же браузере зависает.

Я предоставляю один и тот же файл PDF точно в один и тот же браузер, и на обоих веб-серверах приложение работает в среде 2.0.

Мне еще не удалось получить полезное сообщение об ошибке ни одного из плагинов, когда они выходят из строя.

Мне кажется, что IIS 7.5 как-то портит файл (потому что клиентский браузер и плагин одинаковы) - но мне очень трудно представить, как веб-сервер может ошибиться (это только потоковая передача двоичного клиент ведь).

• Кто-нибудь может подумать, почему поведение IIX 7.0 и 7.5 будет другим?
• Кто-нибудь знает, как получить больше отладочной информации из плагина Adobe или foxit? (если бы я мог получить причину, по которой они выходят из строя, возможно, это дало бы мне ключ к пониманию того, что происходит на сервере неправильно).
• Есть еще какие-нибудь советы по диагностике проблемы?

---

Последующие действия

• Я захватил файлы с помощью wget, и они идентичны .

• Я рассмотрел заголовки запроса и ответа, используя fiddler, и они не делают явного упоминания "Range" в заголовке ответа (или Accept-range в заголовке запроса), что учитывает вероятность проблема с запросами из нескольких частей, предложенная mwalker.

• Я все равно установил MS Hotfix, и это не помогло ситуации (таким образом, Я даже более уверен, что это не «проблема, состоящая из нескольких частей»).

Так что я думаю, что вернулся к новым идеям о том, что может пойти не так!

Ниже приведены заголовки запросов и ответов, которые fiddler записывает при доступе к узлам, работающим на IIS 7.5, 7.0 и 6

.

IIS 7,5

GET /eco/dataFile.aspx?data=147098&record=9754 HTTP/1.1
Host: chrisf
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://chrisf/eco/embeddedMedia.aspx?record=9754&search=true
Cookie: CC=test; 

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 114340
Content-Type: application/pdf
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
Persistent-Auth: true
X-UA-Compatible: IE=8
Date: Mon, 26 Jul 2010 12:47:46 GMT

IIS 7.0

GET /eco/dataFile.aspx?data=147098&record=9754 HTTP/1.1
Host: chris1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://chrisf/eco/Test1.htm
Cookie: CC=test; 

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 114340
Content-Type: application/pdf
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-UA-Compatible: IE=8
Date: Mon, 26 Jul 2010 12:17:15 GMT

IIS 6

GET /mi/dataFile.aspx?data=147098&record=9754 HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://mi-dev/mi/embeddedMedia.aspx?record=9754&search=true
Accept-Language: en-GB
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Host: mi-dev
Connection: Keep-Alive
Cookie: CC=test; 
Authorization: Negotiate YII...

HTTP/1.1 200 OK
Date: Mon, 26 Jul 2010 10:37:47 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYGg...
X-AspNet-Version: 2.0.50727
Content-Length: 114340
Cache-Control: private
Content-Type: application/pdf

Answer 1

OK. Коллега по работе наконец поняла это.

{Нет никакого способа, которым кто-либо на этих форумах мог бы помочь с этим, потому что похоже, что я неправильно понял описание проблемы и не сказал, что плагин PDF находится внутри IFrame (часть информации, которая была жизненно важно для поиска причины). Но все равно спасибо за попытку :)}

В любом случае, вот какая проблема на самом деле: -

IF плагин PDF находится в IFrame AND присутствует заголовок X-UA-Compatible: IE=8, затем плагин аварийно завершает работу в IE.

Нашим решением было просто удалить заголовок X-UA-Compatible: IE=8. Этот заголовок был помещен некоторое время назад как быстрое решение, чтобы исправить некоторые проблемы с рендерингом IE, но с тех пор мы переписали HTML + CSS, и теперь он излишний). Он был включен в web.config примерно так:

   <httpProtocol>
          <customHeaders>
              <clear />
              <add name="X-UA-Compatible" value="IE=8" />
          </customHeaders>
      </httpProtocol>

Причина, по которой мы не увидели эту проблему на IIS6, заключается в том, что IIS 6 не соблюдает это и просто не отправляет заголовок!

Я на 99% уверен, что это проблема: остается 1% сомнений, потому что он не может воспроизвести проблему на Firefox (это была проблема только для IE), и он обнаружил, что может воспроизвести проблему на IIS 7 и 7.5. ,

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

[Машина, на которой я впервые экспериментировал с этой ошибкой, с тех пор превратилась в сервер сборки, поэтому я не могу вернуться к этому и посмотреть, смогу ли я воспроизвести на Firefox]

Answer 2

Я догадываюсь, что вы столкнулись с этим:

Вы не можете открыть некоторые документы PDF с IIS 7.5, используя веб-браузер, в котором включен подключаемый модуль Adobe PDF Reader
http://support.microsoft.com/kb/979543

Многобайтовое mojo!

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

Если вы запускаете Fiddler, вы видите многобайтовый запрос, поступающий от плагина Adobe (или Foxit)?

Похоже, что это может бытьрешение отсюда:

http://dotnetslackers.com/articles/aspnet/Range-Specific-Requests-in-ASP-NET.aspx

Answer 3

Другая потенциальная причина проблем с открытием PDF-файлов в IE из IIS / 7.5 - это когда HTTP / 1.1 отключен в Internet Explorer.См. http://chentiangemalc.wordpress.com/2012/02/16/case-of-the-disappearing-pdf/

Answer 4

У меня была похожая проблема, после того, как многие попытки исправить проблему закончились тем, что сервер отправлял части содержимого ответа до его полного завершения (что нежелательно в файле PDF, особенно если вы используетеChrome PDF Viewer, и я бы сказал, на любой другой файл, кроме HTML / CSS / JS и т. Д.).Так что просто добавили это в ответ, и проблема была решена:

Response.BufferOutput= true;