none
IIS6.0でのステータスコード206回避方法 RRS feed

  • 質問

  • 当方、Windows Server 2003 R2 SP2 + IIS 6.0 で社内向けサイトを構築しております。

     

    その中でASPを利用してPDFやExcelファイルをアップロードし、掲示板として公開しているのですが、

    PDFへのリンクをクリックして表示させようとするとステータスコード「206」が発生して正常に表示されない、

    画面がフリーズしたようになったり何も表示されなくなったりして困っています。

    ただし、毎回発生するわけではないのと、何度かトライしているうちに正常に表示されるようになったりするので

    原因がつかめずにいます。

     

    何か原因や確認すべき項目はありますでしょうか?

    ご存知の方、ご教授頂けますと幸いです。

     

    宜しくお願い致します。

    • 移動 Wang Huang 2012年10月2日 1:45 (移動元:Internet Information Services 5.x, 6.0 - 全般)
    2007年12月14日 0:20

回答

  • ステータスコード206の分かりやすい日本語の解説は以下のサイトでしょうか。
    http://www.studyinghttp.net/status_code#Code206
    http://www.studyinghttp.net/body#Range_Units

    部分的GETとかバイトレンジリクエストとか呼ばれるものですね。

    このサイトはHTTPに関する分かりやすい解説が、RFCの日本語訳を行ったうえで展開されているのでとても有益です。
    Web系に関わる人すべてがブックマークしといた方がよいくらい。

    206 Partial Contentはあくまでクライアントからバイトレンジリクエストが行われたため、その要求に正しく応答しているという結果に過ぎません。IISだろうとApacheだろうと対応している真っ当なHTTPの仕様です。

    正しく処理できないのはコンテンツそのものかクライアントの方が悪い可能性が高いです。


    強引に206 Partial Contentが発生しないようにする方法はありますが、まず根本原因をつきとめて対処した方が良いと思います。





    2008年1月9日 12:54
  • リンク先を読んだならお分かりかと思いますが、206 Partial Contentはレジューム機能などで使用されます。

    なので先に200 OKで返しているログが存在するはずです。

    セットと言えるほど近い時間に記録されているとは限りませんが。

     

    バイトレンジリクエストが一般的なブラウザの通常のブラウジングで普通に発生するものかどうかはちょっと

    分かりませんが、やや特殊なクライアントの中には取得済みのリソースをキャッシュに蓄える場合、その容量に

    よってはすべてを保存しないため、バイトレンジリクエストで残りのデータを要求することがあります。

    IEなどにアドオンされているAdobe Readerプラグインがこのような動作を行うようになっているのかは

    知らないですけれど。

     

    んで、FAQの内容でできることは一通り試されているでしょうか?

    レジストリをいじれっていうのは厳しいにしても、

     

    A. Acrobat または Adobe Reader の最新バージョンをインストール

    B. 旧バージョンのアンインストール

    F. インターネット一時ファイルの削除

    H. Acrobat または Adobe Reader の修復

    I. [PDF をブラウザに表示] オプション

    K. 別の Web サーバで確認します

     

    このあたりは顧客に要求できそうですし。

     

    サーバ側でできることとして

    L. content-type の変更

    M. PDF ファイルの最適化  

    が挙げられていますが、こちらは確認していますか?

     

    バイトレンジリクエストの仕組みから言って、キャッシュの削除とPDFファイルの最適化あたりは有力な気が

    しますけれども。

     

     

    バイトレンジリクエストはクライアントから要求される訳ですが、初回のリソース要求の際にサーバが返す

    Etagというヘッダの情報を必要とします。

    今回の事例とは関係なさそうではありますが、Etagに関連する問題としてこちらも参照してください。

    http://support.microsoft.com/kb/922703/ja

     

     

    んで、あまりオススメしたくない方法ですが。

    Etagヘッダをサーバが出力しなければ現象を抑制することができる可能性はあります。

    IIS6.0のメタベースにOnOffを制御できるプロパティがあればいいのですが、見当たらないので強引に削除します。

    http://www.isapilabs.com/Products/ETagFix/index.htm

    Etagヘッダを制御できるISAPIフィルタのようです。

    私自身は使用したことがないので情報の提供のみですが。。

     

    IIS6.0で使用する場合、

    ・IIS5.0互換の分離モードにする必要がある。(IIS6.0のワーカプロセスは使用できない)

    ・ISAPIフィルタを通さない素の状態に比べ、パフォーマンスが2~3割程度に低下する(経験則)

    などの懸念事項が存在すると思いますので、その点ご注意を。

    この手のソフトは基本的に無保証ってのはもちろんですが。

     

     

    ハイパーリンクで普通にアクセスさせるのではなく、ASP/ASP.NETを介してレスポンスを返すようにすれば

    Etagって生成されないかな?試してないですが、こちらの方がまだマシな解決策かもしれません。

    きちんとIf-Modified-Sinceに対応させれば現実的なパフォーマンス得られそうだし。

    2008年1月21日 15:11
  • 軽く調べてみました。

    500KBほどのPDFですが、初回アクセス(キャッシュがない状態)でIEのAdobe Readerプラグインで開いてみました。

    普通にIEでリンククリックして閲覧してるだけですが。

     

    パケットをキャプチャしたところ、クライアントからのリクエストに200 OKを返しつつチャンク通信が開始されて。

    しばらくしてからクライアントからバイトレンジリクエストが発行され、206 Partial Contentを返してます。

    もちろん閲覧は正常に行えています。

    試しにダウンロードしてみると、206 Partial Contentは発生せず200 OKだけ。

    2回目の閲覧だといきなりバイトレンジリクエストが発生して、206 Partial Content返してました。

    200OK返してる様子は見受けられず。

     

    まあつまり普通に起こることみたいですね。

    PDFに限らずバイナリのダウンロードで行われるチャンク通信ならごく当たり前なのかしら。。

    それともAdobe ReaderがBITSみたく帯域消費し過ぎないようにこういうことやってんのかしら。

    このあたりのノウハウは持ってないので語尾が小さくなってしまいますけれども。

    個人的には、Adobe Readerがメモリ消費を抑制するためになんかやってそうだなあと思ったりも。

    コピーや印刷などのコピーライト制御するために、IEのキャッシュ領域はそのまま使っていない

    ようですし。

    LAN環境では発生しにくいかもしれませんが、正常動作を確認した環境でパケットキャプチャでもやってみれば、

    同じように206 Partial Content発生したりしてるんじゃないでしょうか。

     

    とにかく、上で書いたEtag削除ってのは何の解決にもならないと思いますので、やっぱりお勧めしません。

    クライアント(この場合はAdobe Readerかな)の問題の可能性が高いってことには変わりないと思いますので、

    Adobeが公開している対処法をこなすしか道はないような気がします。

    2008年1月22日 15:23

すべての返信

  • こんにちは~

     

    206 Partial Content のステータス コードは、HTTP 1.1 で認められているコードで、コンテンツを部分的に GET できるというものなので、このステータス コード自体を IIS を返すのが一概に悪いとは言えない気がします。

    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html (英語: どなたかわかりやすい日本語サイトをご存知ならレスお願いします)

     

    そうなると、この現象はクライアント依存(特定のクライアントだけで発生するのか?)や、ブラウザは何のどのバージョンを使っているのかなどの情報があると、フォーラムを見ている方々からの意見をもらいやすくなると思いますよ

    2007年12月28日 6:23
  • ステータスコード206の分かりやすい日本語の解説は以下のサイトでしょうか。
    http://www.studyinghttp.net/status_code#Code206
    http://www.studyinghttp.net/body#Range_Units

    部分的GETとかバイトレンジリクエストとか呼ばれるものですね。

    このサイトはHTTPに関する分かりやすい解説が、RFCの日本語訳を行ったうえで展開されているのでとても有益です。
    Web系に関わる人すべてがブックマークしといた方がよいくらい。

    206 Partial Contentはあくまでクライアントからバイトレンジリクエストが行われたため、その要求に正しく応答しているという結果に過ぎません。IISだろうとApacheだろうと対応している真っ当なHTTPの仕様です。

    正しく処理できないのはコンテンツそのものかクライアントの方が悪い可能性が高いです。


    強引に206 Partial Contentが発生しないようにする方法はありますが、まず根本原因をつきとめて対処した方が良いと思います。





    2008年1月9日 12:54
  • こんにちは~

     

    OakBow さん、

    非常に参考になる投稿をありがとうございました! たしかにこのサイトはわかりやすいですね

     

    こぅぎぃさん、いかがでしょうか ?

    OakBow さんの回答が本件では的確な内容であると思いましたので、回答済みチェックをつけさせていただきました。

     

    回答済みチェックが付くことにより、有用な情報を探している方が情報を見つけやすくなります。
    問題解決につながる回答があった場合は、なるべく回答済みボタンを押してチェックを付けてくださいね

    こぅぎぃ さんは設定を元に戻すこともできますので、もし不適切でしたら、修正をお願いします。

     

    また何かありましたら、過去のスレッドも含め、フォーラムの情報を参考になさってください

    2008年1月17日 10:23
  • 鹿島様、OakBow様

     

    #返答遅くなり恐縮です。。

    非常に参考になる情報ありがとうございます。

    参考URLの方拝見させていただきました。ありがとうございました。

     

    どうも自分の質問内容がマトを得ていなかったようです。失礼しました。。

     

    状況を整理しますと、

    Windows 2003 Server + IIS 6.0 の環境でWEBサイトを構築しております。

    その中でサーバー上のPDFファイルに<A>タグでリンクを貼っておるのですが、ユーザーの中にはPDFが正常に表示できないケースがあるようなのです。

    正常に表示出来ないというのは、ファイルの読み込みが途中で止まってしまったり、画面が白くなったりするようです。

     

    ログから何かわからないかとその該当時間帯にあるIISログからPDFへのアクセスを見たところ、

    206のみ記録されていたので206を回避出来ればよいのかと勘違いしていました。

    #正常なログだと206と200がセットで記録されるかと。

    以前の環境(Windows 2000 Server + IIS 5.0)の時はこのような問合せ(トラブル)は聞いたことがなかったので

    サーバー環境によるものではないのかと思い、OSやIISで設定がないかと探しておりました。

     

    収集できている情報ですと特定の環境ではなさそうなので表示できない場合には一時的にローカルに保存してから開くように案内している状況です。

    ただし、LAN環境の自分のPC(XP+IE7)からですと上記の症状は確認できていません。

     

    Adobeのサポートではいくつか回避方法が掲載されておりますが、大抵がクライアント環境の設定変更によるものなので

    サーバー側でどうにか出来ないかと考えておりました。

    http://support.adobe.co.jp/faq/faq/qadoc.sv?230411+002

     

    引き続き情報ございましたらご提供頂けますと幸いです。

    宜しくお願い致します。

     

    2008年1月21日 0:39
  • リンク先を読んだならお分かりかと思いますが、206 Partial Contentはレジューム機能などで使用されます。

    なので先に200 OKで返しているログが存在するはずです。

    セットと言えるほど近い時間に記録されているとは限りませんが。

     

    バイトレンジリクエストが一般的なブラウザの通常のブラウジングで普通に発生するものかどうかはちょっと

    分かりませんが、やや特殊なクライアントの中には取得済みのリソースをキャッシュに蓄える場合、その容量に

    よってはすべてを保存しないため、バイトレンジリクエストで残りのデータを要求することがあります。

    IEなどにアドオンされているAdobe Readerプラグインがこのような動作を行うようになっているのかは

    知らないですけれど。

     

    んで、FAQの内容でできることは一通り試されているでしょうか?

    レジストリをいじれっていうのは厳しいにしても、

     

    A. Acrobat または Adobe Reader の最新バージョンをインストール

    B. 旧バージョンのアンインストール

    F. インターネット一時ファイルの削除

    H. Acrobat または Adobe Reader の修復

    I. [PDF をブラウザに表示] オプション

    K. 別の Web サーバで確認します

     

    このあたりは顧客に要求できそうですし。

     

    サーバ側でできることとして

    L. content-type の変更

    M. PDF ファイルの最適化  

    が挙げられていますが、こちらは確認していますか?

     

    バイトレンジリクエストの仕組みから言って、キャッシュの削除とPDFファイルの最適化あたりは有力な気が

    しますけれども。

     

     

    バイトレンジリクエストはクライアントから要求される訳ですが、初回のリソース要求の際にサーバが返す

    Etagというヘッダの情報を必要とします。

    今回の事例とは関係なさそうではありますが、Etagに関連する問題としてこちらも参照してください。

    http://support.microsoft.com/kb/922703/ja

     

     

    んで、あまりオススメしたくない方法ですが。

    Etagヘッダをサーバが出力しなければ現象を抑制することができる可能性はあります。

    IIS6.0のメタベースにOnOffを制御できるプロパティがあればいいのですが、見当たらないので強引に削除します。

    http://www.isapilabs.com/Products/ETagFix/index.htm

    Etagヘッダを制御できるISAPIフィルタのようです。

    私自身は使用したことがないので情報の提供のみですが。。

     

    IIS6.0で使用する場合、

    ・IIS5.0互換の分離モードにする必要がある。(IIS6.0のワーカプロセスは使用できない)

    ・ISAPIフィルタを通さない素の状態に比べ、パフォーマンスが2~3割程度に低下する(経験則)

    などの懸念事項が存在すると思いますので、その点ご注意を。

    この手のソフトは基本的に無保証ってのはもちろんですが。

     

     

    ハイパーリンクで普通にアクセスさせるのではなく、ASP/ASP.NETを介してレスポンスを返すようにすれば

    Etagって生成されないかな?試してないですが、こちらの方がまだマシな解決策かもしれません。

    きちんとIf-Modified-Sinceに対応させれば現実的なパフォーマンス得られそうだし。

    2008年1月21日 15:11
  • 軽く調べてみました。

    500KBほどのPDFですが、初回アクセス(キャッシュがない状態)でIEのAdobe Readerプラグインで開いてみました。

    普通にIEでリンククリックして閲覧してるだけですが。

     

    パケットをキャプチャしたところ、クライアントからのリクエストに200 OKを返しつつチャンク通信が開始されて。

    しばらくしてからクライアントからバイトレンジリクエストが発行され、206 Partial Contentを返してます。

    もちろん閲覧は正常に行えています。

    試しにダウンロードしてみると、206 Partial Contentは発生せず200 OKだけ。

    2回目の閲覧だといきなりバイトレンジリクエストが発生して、206 Partial Content返してました。

    200OK返してる様子は見受けられず。

     

    まあつまり普通に起こることみたいですね。

    PDFに限らずバイナリのダウンロードで行われるチャンク通信ならごく当たり前なのかしら。。

    それともAdobe ReaderがBITSみたく帯域消費し過ぎないようにこういうことやってんのかしら。

    このあたりのノウハウは持ってないので語尾が小さくなってしまいますけれども。

    個人的には、Adobe Readerがメモリ消費を抑制するためになんかやってそうだなあと思ったりも。

    コピーや印刷などのコピーライト制御するために、IEのキャッシュ領域はそのまま使っていない

    ようですし。

    LAN環境では発生しにくいかもしれませんが、正常動作を確認した環境でパケットキャプチャでもやってみれば、

    同じように206 Partial Content発生したりしてるんじゃないでしょうか。

     

    とにかく、上で書いたEtag削除ってのは何の解決にもならないと思いますので、やっぱりお勧めしません。

    クライアント(この場合はAdobe Readerかな)の問題の可能性が高いってことには変わりないと思いますので、

    Adobeが公開している対処法をこなすしか道はないような気がします。

    2008年1月22日 15:23