質問

ASP.NET 2.0のブラウザにPDFをストリーミングしています。これは、HTTPを介したすべてのブラウザーとHTTPSを介したIEを除くすべてのブラウザーで機能します。私の知る限り、これはIEのすべてのバージョンで(過去5年ほど)動作していましたが、クライアントは問題を報告し始めたばかりです。 暗号化されたページをディスクに保存しないセキュリティオプションはデフォルトで無効になっており、ある時点でデフォルトで有効になったと思われます(インターネットオプション->詳細->セキュリティ)。このオプションをオフにすると、回避策として役立ちますが、長期的なソリューションとしては実行できません。

受け取ったエラーメッセージは次のとおりです。

  

Internet Explorerは、www.sitename.comからOutputReport.aspxをダウンロードできません。

     

Internet Explorerはこのインターネットサイトを開くことができませんでした。要求されたサイトは利用できないか、見つかりません。後でもう一度やり直してください。

PDFの作成に使用されるツールは、 DataDynamics のActiveReportsです。 PDFが作成されたら、それを送信するコードを次に示します。

Response.ClearContent()
Response.ClearHeaders()
Response.AddHeader("cache-control", "max-age=1")
Response.ContentType = "application/pdf"
Response.AddHeader("content-disposition", "attachment; filename=statement.pdf")
Response.AddHeader("content-length", mem_stream.Length.ToString)
Response.BinaryWrite(mem_stream.ToArray())
Response.Flush()
Response.End()  

注:cache-controlを明示的に指定しない場合、.NETは代わりにno-cacheを送信するので、cache-controlをprivateまたはpublicまたはmaxage =#に設定しようとしましたが、いずれも仕事。

ここにひねりがあります:Fiddlerを実行して応答ヘッダーを検査すると、すべてが正常に機能します。私が受け取るヘッダーは次のとおりです。

  

HTTP / 1.1 200 OK
  Cache-Control:max-age = 1
  日付:2009年7月29日水曜日17:57:58 GMT
  コンテンツタイプ:application / pdf
  サーバー:Microsoft-IIS / 6.0
  MicrosoftOfficeWebServer:5.0_Pub
  X-Powered-By:ASP.NET
  X-AspNet-Version:2.0.50727
  content-disposition:添付; filename = statement.pdf
  コンテンツエンコーディング:gzip
  変化:Accept-Encoding
  Transfer-Encoding:チャンク

Fiddlerをオフにして再試行するとすぐに、再び失敗します。私が気づいたもう1つのことは、Fiddlerの実行中にこのウェブサイトのセキュリティ証明書に問題がある警告メッセージが表示され、このウェブサイトに進む(推奨されません)をクリックする必要があることですを通過します。 Fiddlerがオフの場合、このセキュリティ警告は表示されず、すぐに失敗します。

Fクライアントマシンを変更せずに

更新: Fiddlerの問題は解決されました。ありがとうございますEricLaw、それで一貫して動作するようになりました(壊れた、Fiddlerの実行の有無にかかわらず)。

Googleの検索に基づいて、ウェブ全体にこの同じ問題のレポートがたくさんあるようです。それぞれのレポートは、個々のケースの問題を修正しているように見える応答ヘッダーの特定の組み合わせを持っています。 ETag、LastModified日付の追加、Varyヘッダーの削除(Fiddlerを使用)、Cache-ControlヘッダーやPragmaヘッダーの多数の組み合わせなど、これらの提案の多くを試しました。 " Content-Transfer-Encoding:binary"を試しました。 " application / force-download" ContentTypeの場合。今のところ何も助けていない。 いくつか Microsoft KB 記事。これらはすべて Cache-Control:no-cache が原因であることを示しています。他のアイデアはありますか?

更新:ところで、完全を期すため、この同じ問題はExcelおよびWordの出力でも発生します。

更新:進展はありません。 .SAZファイルをメールで送信しました

役に立ちましたか?

解決 2

ワイルドグースチェイスで2週間後、暗号化されたページをディスクに保存しない場合、この方法でPDF、Excel、またはWord文書をストリーミングできるコード変更の組み合わせを見つけることができませんでした 'オプションがオンになっています。

Microsoftは、この動作は多くのKB記事およびプライベートメールの仕様によるものであると述べています。 「暗号化されたページをディスクに保存しない」オプションがオンになっていると、IEは正しく動作し、指示どおりに動作しているようです。 この投稿は、これまでに見つけた最高のリソースですこの設定が有効になる理由と、有効にすることの長所と短所について説明します。

  
    
      

" SSL(HTTPS)接続を扱う場合、「暗号化されたページをディスクに保存しない」が有効になります。 Webサーバーがファイルのキャッシュ方法に関する完了情報を送信できるように、Webサーバーからのアドバイスがあるかどうかに関係なく、SSL(HTTPS)接続中にファイルをキャッシュに保存しないようにInternet Explorerを基本的に設定できます。

             

この機能を有効にする利点は何ですか、セキュリティが機能を有効にする最大の理由です。ページはインターネット一時ファイルのキャッシュに保存されません。

             

マイナス面は何ですか? 1バイトのgif画像がページ上で数十回使用されていてもキャッシュに何も保存されないため、毎回Webサーバーからフェッチする必要があるため、パフォーマンスが低下します。さらに悪いことに、ダウンロードしたファイルが削除されたり、エラーが表示されたりPDFドキュメントを開いたりするなど、いくつかのユーザーアクションが失敗する場合があります。"

    
  

現時点で見つけることができる最善の解決策は、この設定を使用する代わりの方法があることをクライアントとユーザーに伝えることです。

  
    
      

"「ブラウザを閉じたときに空の一時インターネットファイルフォルダ」を使用します。ブラウザが閉じるたびに、ブラウザの別のインスタンスまたは外部アプリケーションからのファイルにロックがないと仮定して、すべてのファイルがキャッシュから削除されます。

             

暗号化されたページをディスクに保存しない」を利用する前に、多くの考慮が必要です。すばらしいセキュリティ機能のように聞こえますが、この機能を使用した結果、ダウンロードの失敗やパフォーマンスの低下のためにヘルプデスクの呼び出しが発生する可能性があります。     

  

他のヒント

Cache-Control ヘッダーが正しくありません。 Cache-Control:max-age = 1 で、中央にダッシュがあります。最初に修正して、違いが生じるかどうかを確認してください。

通常、最も可能性の高い犯人はVaryヘッダーであると言います。このようなヘッダーは、IEでのキャッシュに問題を引き起こすことが多いためです。 http://blogs.msdn.com/ieinternals/archive/2009/06/17/9769915.aspx 。応答ヘッダーに ETAG を追加してみてください。

Fiddlerは、(ルールを書いていない限り)キャッシュ可能性に影響を与えないはずです。そうすると言っているように聞こえますが、これはおそらく何らかのタイミングの問題があることを示唆しています。

>暗号化されたページをデフォルトで無効にされていたディスクセキュリティオプションに保存しないでください

このオプションは がデフォルトで無効になっています(IE6、7、および8)。ただし、IT管理者はグループポリシーを使用して有効にできます。一部の大手企業は無効にしています。

ちなみに、Fiddlerの実行中に証明書エラーが表示される理由は、Fiddlerのルート証明書を信頼することを選択していないためです。 http://www.fiddler2.com/fiddler/help/httpsdecryption.aspこのトピックの詳細について。

ストリーミングしたいPDFファイルで同様の問題が発生しました。 Response.ClearHeaders()を使用しても、実行時にプラグマヘッダーとCache-Controlヘッダーが追加されました。解決策は、IISのヘッダーをクリアすることでした(右クリック-> PDFを読み込んでいるページの[プロパティ]、[Httpヘッダー]タブ)。

これは私にとってはうまくいくように見えました:

Dim browser As System.Web.HttpBrowserCapabilities = Request.Browser
If (browser.Browser = "IE") Then
  Response.AppendHeader("cache-control", "private") ' ie only
Else
  Response.AppendHeader("cache-control", "no-cache") ' all others (FF/Chrome tested)
End If

私たちは昔、同様の問題に直面していました-私たちがやったのは私たちです(これはJava EEです)。 Webアプリケーションの設定に

を追加します
<mime-mapping>
    <extension>PDF</extension>
    <mime-type>application/octet-stream</mime-type>
</mime-mapping>

これにより、ブラウザがレンダリングしようとする代わりに、WebアプリケーションからのPDFがダウンロードされます。

編集:ストリーミングしているように見えます。その場合、構成ではなくコードでmime-typeをapplication / octet-streamとして使用します。したがって、ここでは

の代わりに
Response.ContentType = "application/pdf"

使用します

Response.ContentType = "application/octet-stream"

IEのバージョンMicrosoftがこの問題に対して IE6のホットフィックスをリリースしたことを思い出します。それが何らかの役に立つことを願っていますか?

キャッシュコントロールグースチェイスを読みましたが、私の、私のニーズに合った、それが助けになる場合。

gzip圧縮を無効にしてみてください。

リンクを経由する代わりに、誰かがこれが役立つと思うことを期待して、ここに追加します。

ここに私のコードがあります

    byte[] bytes = // get byte array from DB

    Response.Clear();
    Response.ClearContent();
    Response.ClearHeaders();
    Response.Buffer = true;

    // Prevent this page from being cached.
    //  NOTE: we cannot use the CacheControl property, or set the PRAGMA header value due to a flaw re: PDF/SSL/IE
    Response.Expires = -1; 

    Response.ContentType = "application/pdf";
    // Specify the number of bytes to be sent
    Response.AppendHeader("content-length", bytes.Length.ToString());

    Response.BinaryWrite(bytes);    

            // Wrap Up
    Response.Flush();
    Response.Close();
    Response.End();

OPのように、これを機能させるために何日も頭を悩ませていましたが、最後にそれをやったので、ヘッダーの「組み合わせ」を共有すると思いました:

            if (System.Web.HttpContext.Current.Request.Browser.Browser == "InternetExplorer"
                && System.Web.HttpContext.Current.Request.Browser.Version == "8.0")
            {
                System.Web.HttpContext.Current.Response.Clear();
                System.Web.HttpContext.Current.Response.ClearContent();
                System.Web.HttpContext.Current.Response.ClearHeaders();
                System.Web.HttpContext.Current.Response.ContentType = "application/octet-stream";

                System.Web.HttpContext.Current.Response.AppendHeader("Pragma", "public");
                System.Web.HttpContext.Current.Response.AppendHeader("Cache-Control", "private, max-age=60");
                System.Web.HttpContext.Current.Response.AppendHeader("Content-Transfer-Encoding", "binary");

                System.Web.HttpContext.Current.Response.AddHeader("content-disposition", "attachment; filename=" + document.Filename);
                System.Web.HttpContext.Current.Response.AddHeader("content-length", document.Data.LongLength.ToString());

                System.Web.HttpContext.Current.Response.BinaryWrite(document.Data);
            }

誰かを苦痛から救う希望!

SSLを介してPDFをストリーミングし、これをiframeまたはオブジェクト内に配置しようとすると、同様の問題が発生しました。 aspxページがセキュリティで保護されていないバージョンのURLにリダイレクトし続け、ブラウザーがそれをブロックすることがわかりました。

ASPXページからASHXハンドラーに切り替えると、リダイレクトの問題が修正されました。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top