C# BinaryWrite через SSL
Я пытаюсь ответить клиенту PDF-файлом, хранящимся в поле MSSQL varbinary (MAX). Ответ работает на моем локальном хосте и тестовом сервере через http-соединение, но не работает на производственном сервере через https-соединение. Я использую простой BinaryWrite (код ниже).
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);
Редактировать: Если файл просматривается через http на производственном сервере, браузер отображает код PDF-файла, как если бы он просматривался через Блокнот. (например,% PDF-1.4% âãÏÓ 6 0 obj <> endobj xref 6 33 ... и т. д.)
Проверьте правку в вопросе для ответа.
Ответы 6
Пару лет назад я столкнулся с той же проблемой. Найденное нами решение было не самым красивым. Мы записали файл на диск и сделали Response.Redirect на него.
Можете ли вы использовать Wireshark (или аналогичный), чтобы узнать, что происходит с клиентом?
Какие данные в Wireshark мне нужны? Я вижу первый запрос по протоколу TLSv1. У меня есть инструмент, но я действительно не знаю, как понять результаты. Спасибо.
Fiddler, наверное, лучше для таких вещей.
Только что отправил необработанный запрос от Fiddler
IE 7 имеет / имел пантомима типа "проблема" с PDF, связанный с запутанные правила пантомимы. Вы можете проверить, есть ли у клиента этот патч.
Также были спорадические жалобы на пустые страницы IE 7 по другим причинам (теги сценария, response.flush и пакеты поддержки активности среди них), которые, AFAIK, не были надежно решены.
К счастью, похоже, что это происходит каждый раз, так что вы сможете довольно быстро разобраться в этом.
Вы можете попробовать связать .pdf с ASP.NET, чтобы URL-адрес воспринимался IE как PDF-файл. Это должно перекрыть проблему с типом пантомимы.
Перенаправления (HTTP Response.Redirect, на основе Javascript и ссылки), похоже, помогают в некоторых других проблемах.
Проверка настроек поддержки активности IIS на рабочем сервере или просмотр с помощью Fiddler покажет вам, являются ли сообщения поддержки активности проблемой.
Может быть добавление заголовка content-disposition могло бы помочь ... Это, однако, не в моей голове.
Я предполагаю, что отношение SSL - отвлекающий маневр, поэтому я бы также проверил, не использует ли SSL на производственном сервере.
Вот необработанный запрос, просмотренный в Fiddler
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
Редактировать: Вот необработанные заголовки ответов, просматриваемые в Fiddler
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
Кстати, вы должны переместить этот пост в свой вопрос
Мне просто удалось обойти это, заменив
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();
Спасибо. У меня это тоже сработало, оказалось, что вам нужно использовать Response.BinaryWrite. Остальные (Transmitfile, outputstream.write, writefile) не работали.
На самом деле ключ к этому ответу - заголовок Content-Length. У меня была проблема с BinaryWrite с docx, пока я не добавил заголовок, чтобы явно указать размер содержимого.
Сначала это не сработало, но после копирования настроек все заработало. Я думаю, что в моем случае ключевым моментом был Response.AddHeader ("Content-Length", ...
Столкнулся с той же проблемой. Тоже только с IE. Исправил мой, удалив <%@ OutputCache Location = "None" %> со страницы .aspx. Это, возможно, объяснило бы, почему вызов Response.ClearHeaders работал выше.
Определите «не работает». Исключения? Неверный вывод?