2008-12-10 4 views
4

Я пытаюсь ответить клиенту с PDF, хранящимся в поле MSSQL varbinary (MAX). Ответ работает на моем локальном хосте и тестовом сервере по http-соединению, но не работает на рабочем сервере через соединение https. Я использую просто BinaryWrite (код ниже).C# BinaryWrite через SSL

byte[] displayFile = DatabaseFiles.getPdfById(id); 

    Response.ContentType = "application/pdf"; 
    Response.BinaryWrite(displayFile); 

Ничего особенного здесь. Просто возьмите двоичные данные, установите тип содержимого и напишите обратно клиенту. Есть ли что-то особенное, что нужно сделать для того, чтобы ответить на https таким образом?

Редактировать: Не работает, я имею в виду, что я получаю пустой документ в браузере. Acrobat не загружается в браузере.

Редактировать: Я только заметил, что эта проблема возникает только в IE 7. PDF загружается правильно в Firefox 3. Наш клиент использует только IE 7 (лучше IE 6, который я убедил их в обновлении от ... lol).

Редактировать: Попытался добавить заголовок «content-disposition», чтобы файл работал как вложение. Браузеру не удалось загрузить под SSL с ошибкой IE «Internet Explorer не может загрузить displayFile.aspx с ProductionServer.net». (Код ниже)

byte[] displayFile = DatabaseFiles.getPdfById(id); 
    Response.Clear(); 
    Response.AddHeader("content-disposition", String.Format("attachment;filename={0}", fileName)); 
    Response.ContentType = "application/pdf"; 
    Response.BinaryWrite(displayFile); 

Edit: Если файл рассматривается через HTTP на производственном сервере, браузер отображает код для PDF, как это было просматриваемого через NotePad. (например,% PDF-1.4% âãÏÓ 6 0 obj <> endobj xref 6 33 ... и т. д.)

+0

Определить, что «не работает». Исключения? Неверный выход? – 2008-12-10 15:57:03

+0

Проверьте правильность ответа на вопрос. – Eddie 2008-12-10 16:11:10

ответ

8

Я только что удалось обойти эту проблему путем замены

Response.Clear(); 

с

Response.ClearContent(); 
Response.ClearHeaders(); 

так что все выглядит следующим образом:

byte[] downloadBytes = doc.GetData(); 
Response.ClearContent(); 
Response.ClearHeaders(); 

Response.Buffer = true; 
Response.ContentType = "application/pdf"; 
Response.AddHeader("Content-Length", downloadBytes.Length.ToString()); 
Response.AddHeader("Content-Disposition", "attachment; filename=myFile.pdf"); 
Response.BinaryWrite(downloadBytes); 
Response.Flush(); 
Response.End(); 
0

Я столкнулся с той же проблемой пару лет назад. Решение, которое мы нашли, было не самым красивым. Мы написали файл на диск и выполнили Response.Redirect.

0

Можете ли вы использовать Wireshark (или аналогичный), чтобы узнать, что происходит с клиентом?

+0

Какие данные в Wireshark я ищу? Я вижу первый запрос по протоколу TLSv1. У меня есть инструмент, но я не знаю, как понять результаты. Благодарю. – Eddie 2008-12-10 16:19:47

+0

Fiddler, вероятно, будет лучше для такого рода вещей. – 2008-12-10 17:08:55

1

IE 7 имеет/имеет mime type "issue" с PDF, относящийся к convoluted mime type rules. Вы можете проверить, имеет ли клиент этот патч.

Также были спорадические жалобы на пустые страницы IE 7 из-за других причин (теги сценариев, response.flush и keepalives среди них), которые AFAIK не были надежно решены.

К счастью, звучит так, как будто это происходит каждый раз - так что вы должны быть в состоянии добраться до сути довольно быстро.

Вы можете попробовать связать .pdf с ASP.NET, чтобы URL-адрес был выбран как файл PDF в IE. Это должно переопределить проблему типа mime.

Перенаправления (HTTP Response.Redirect, Javascript и ссылки), похоже, помогают другим.

Проверка настроек IAL на рабочем сервере или просмотр с помощью Fiddler покажет вам, есть ли проблемы с keepalives.

Возможно,, добавив заголовок содержания, поможет ... Это, однако, с головы.

Мое предположение, что отношение SSL является красной селедкой, поэтому я также проверю с помощью не-SSL на производственном сервере.

0

Вот исходный запрос, как показано на Скрипач

GET /displayFile.aspx?id=128 HTTP/1.1 
Accept: */* 
Accept-Language: en-us 
UA-CPU: x86 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618) 
Host: ProductionServer.net 
Connection: Keep-Alive 

Edit: Вот исходные заголовки отклика, как показано на Скрипач

HTTP/1.1 200 OK 
Date: Wed, 10 Dec 2008 18:39:54 GMT 
Server: Microsoft-IIS/6.0 
X-Powered-By: ASP.NET 
X-AspNet-Version: 2.0.50727 
Cache-Control: no-cache 
Pragma: no-cache 
Expires: -1 
Content-Type: application/pdf; charset=utf-8 
Content-Length: 102076 
1

Столкнулся с той же проблемой. Также только с IE. Исправлена ​​моя, удаляя <%@ OutputCache Location="None" %> с страницы .aspx. Возможно, это объясняет, почему вызов Response.ClearHeaders работал выше.

Смежные вопросы