4

MSSQL varbinary(MAX) フィールドに格納された PDF でクライアントに応答しようとしています。応答は、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 からアップグレードするよう説得しました...笑)。

編集：ファイルを添付ファイルとして機能させるために、ヘッダー「content-disposition」を追加しようとしました。IE エラー「Internet Explorer は、ProductionServer.net から displayFile.aspx をダウンロードできません。(以下のコード)

    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 ...など)

4

6 に答える 6

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();
于 2009-02-18T16:42:15.870 に答える
1

同じ問題に遭遇しました。こちらもIEのみ。<%@ OutputCache Location="None" %>.aspx ページから削除して修正しました。Response.ClearHeadersこれはおそらく、上記の呼び出しが機能した理由を説明するでしょう。

于 2011-02-18T22:50:29.560 に答える
1

IE 7 には、複雑な MIME タイプ ルールに関連する PDFのMIME タイプ「問題」があります。クライアントにそのパッチがあるかどうかを確認することができます。

また、他の理由 (script タグ、response.flush、キープアライブ) による IE 7 の空白ページの散発的な苦情もあり、私の知る限り、確実に解決されていません。

幸いなことに、これは毎回発生しているように思われるので、すぐに原因を突き止めることができるはずです。

URL が IE によって PDF ファイルとして取得されるように、.pdf を ASP.NET に関連付けてみることができます。これにより、MIME タイプの問題が上書きされます。

リダイレクト (HTTP Response.Redirect、Javascript ベース、およびリンク) は、他のいくつかの問題に役立つようです。

運用サーバーで IIS キープアライブ設定を確認するか、Fiddler で監視すると、キープアライブに問題があるかどうかがわかります。

content-disposition ヘッダーを追加すると役立つかもしれません。

私の推測では、SSL 関係はニシンなので、本番サーバーでも非 SSL で確認します。

于 2008-12-10T17:22:45.417 に答える
0

私は数年前に同じような問題に遭遇しました。私たちが見つけた解決策は、最も美しいものではありませんでした。ファイルをディスクに書き込み、それに Response.Redirect を実行しました。

于 2008-12-10T16:01:21.057 に答える
0

Wireshark (または同様のもの) を使用して、クライアントに何が届いているかを確認できますか?

于 2008-12-10T16:13:39.537 に答える
0

これは、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
于 2008-12-10T18:12:45.690 に答える