C # BinaryWrite через SSL

Question

Я пытаюсь ответить клиенту 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).

Редактировать: Попытка добавить заголовок "расположение содержимого", чтобы файл действовал как вложение. Не удалось загрузить браузер по протоколу 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 ... и т. д.)

Answer 1

Мне только что удалось обойти это, заменив

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();

Answer 2

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

Answer 3

В IE 7 была / была проблема типа mime с PDF, связанная с правилами извилистого типа mime . Вы можете проверить, есть ли у клиента этот патч.

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

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

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

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

Проверка настроек поддержки активности IIS на производственном сервере или просмотр с помощью Fiddler покажет вам, являются ли ошибки поддержки активности.

Может быть, добавление заголовка размещения контента помогло бы ... Хотя это не в моей голове.

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

Answer 4

Вот необработанный запрос в 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

Answer 5

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

Answer 6

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