none
IE9にてRequest内容を分割して送信? RRS feed

  • 質問

  • はじめまして。

    IE9×Windows7を利用中です。

    以前、どこかで「IE7以降(か、IE8以降か・・)で、ブラウザが勝手にRequest内容を分割して送信する」という記事を見かけた気がするのですが
    どこだったか見つけられません。

    現在、IE9にてWebアプリケーションを利用中に、フリーズして1分ほどすると以下のメッセージが出力される事象が複数回に一度発生しております。
    □ポップアップメッセージ内容
    「サーバーへ接続できません。(status=12031)」
    ※statusコードは現在のところ3種類確認しています。

    クライアントにパケットキャプチャを仕込み、APPサーバにtcpdump、クライアントとAPPサーバの間にあるSSOサーバにもtcpdumpを仕込みました。

    調査した結果、以下のことがわかりました。

    ・クライアントからRequest要求 → SSOサーバ、APPサーバまで接続確立
    ・APPサーバにてデータを待つも送られてこず、5秒でタイムアウト。切断
    ・SSOサーバもクライアントからのデータを待つも、タイムアウトとなったため、クライアントへリセットを返却しようとする
    ・SSOサーバがリセットを返却する前に、クライアントから来ていたデータをAPPサーバへ送信しようとするも、BackENDとは切断済みのため、リセットを返却
    ・ポップアップ発生

    なお、クライアントからSSOサーバへきているデータとは、ヘッダーまで来ているようです。
    その後、BODYが送信されていないようです。

    まさしく冒頭の分割して送ってしまっている、、という記事が関係ありそうなのですが・・。
    情報お持ちの方いらっしゃいませんでしょうか?

    2014年4月25日 8:49

回答

すべての返信

  • # これが原因かはわかりませんが思い付いたので

    HTTPのレスポンスステータスには 100 Continue というものがあります。この場合、WebブラウザーとWebサーバーとのやり取りは次のようなステップになります。

    1. WebブラウザーからWebサーバーに対してリクエストヘッダーのみ送信(ヘッダーにはExpect: 100-continueが付きます)
    2. WebサーバーからWebブラウザーに対して100 Continueを返信
    3. WebブラウザーからWebサーバーに対してリクエストボディーの送信
    4. WebサーバーからWebブラウザーに対してステータスコードを含む本来のレスポンスを返信

    100 Continue未対応のWebサーバーは417 Expectation Failedを返さなければなりません。しかしそれすら未対応のWebサーバーはWebブラウザーからのリクエストボディー待ちで止まってしまいます。その場合、Webブラウザーも100 Continue待ちですので質問の状況になり得ますし、これが原因かもしれません。Webサーバーだけでなく中継するProxyサーバーで止まっていることもあります。

    tcpdumpにてWebブラウザーからのリクエストにExpectヘッダーが含まれているかで判断可能です。

    これが原因の場合、Webサーバーが100 Continue未対応であれば、インターネットオプションからHTTP/1.1の使用するのチェックを外し、中継するProxyサーバーが未対応であれば、プロキシ接続でHTTP/1.1を使用するのチェックを外すことです。その場合、Webブラウザーは100 Continueを使用しなくなります。
    # 他の回避策があるかまでは確認していません。

    これが原因の場合、HTTP/1.1において100 Continueへの対応は必須ですので、根本的には正しく実装されたWebサーバー・Proxyサーバーに更新すべきです。

    2014年4月25日 22:07
  • 佐祐理さま!

    返信ありがとうございます。

    なんと。まさしくそんな感じですね。。

    早速確認してみます。

    わかり次第ここでご連絡いたします。

    2014年4月26日 7:58
  • 昔だとこういうのがありました。

    You cannot log on to a Web site or complete an Internet transaction, or you receive an HTTP 500 (Internal Server Error) Web page (http://support.microsoft.com/kb/831167/en-us)

    ただ、"IE POST body missing" などで検索すると、特定条件で類似の現象が起きるという話が時々でてきますね。

    ご参考まで。


    hebikuzure

    • 回答としてマーク oki_mee 2014年5月8日 0:04
    2014年4月26日 12:24
    モデレータ
  • 以下が該当事象そのもののように思えました。
     
    Challenge-Response Authentication and Zero-Length Posts - IEInternals
     
    IEは通信先サーバがKerberos風の認証を使用している場合、
    パフォーマンス向上のため、401応答が期待されるケースで(すぐに?)ボディ部を送信しないよようです。
    oki_meeさんの事象は、URLがディレクトリのときは正しく末尾/を付与すれば回避できるかもしれません。
    # 英語間違っていたらご指摘お願いいたします。
    2014年4月26日 15:21
  • hebikuzureさま

    ありがとうございます。
    語学力のなさに、Google翻訳に頼り切っていますが
    確か私が冒頭で「知りませんか?」と言っていた件がそのような話だったと思います。
    以前でたWindowsUpdateのせいでどうのこうの・・というような。

    IE POST body missing なるほど。
    これらの単語をヒントに検索してみます。



    (´・ω・`)さま

    ありがとうございます。
    ”Kerberos風の認証”のところから勉強します。
    とりあえず、SSOサーバを利用した認証に限って言えば、ファイル名までの指定ですので、ディレクトリで終わっているURLはないと認識しています。
    とはいえ、該当Webアプリケーションの認証や私の関知しないところでの処理があるとしたら、不明です。

    ひとまず教えていただいたページをGoogle翻訳にかけて読みこみますw
    2014年4月28日 4:24
  • 当初質問していた記事は、こちらでした(みつけました!)

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

    hebikuzureさまが教えてくださったのと同じですよね。ありがとうございます。


    いま、みなさまから返信いただいた候補にプラスして、以下の可能性も考えています。
    ・クライアントから接続要求、接続確立
    ・SSOサーバにてKeepAlive発生
    ・クライアントがRequest送信(ブラウザのKeepAliveは1分なので、接続を再利用しようとする)
    ・しかし既に切断済であり、IEはRetryするも、上記リンクの内容から、ヘッダーしか送信せず(ここは直接関係ないが、当初の投稿内容はここに一致?)
     →この場合、SSOサーバのKeep-Alive値をブラウザより大きくする。

    更に、今回は、SSOサーバとAPPサーバの間にもそれが発生している可能性があると考えます。


    パケットの流れの見落としの可能性もあるので、再度パケットを追う予定です。
    ※接続確立後に、Request送信、さらにRetryしていて、さらにヘッダーしか送信していなかったら、この現象と判断できると思っています。
    2014年4月28日 8:09
  • パケット確認いたしました!

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

    こちらについて、現在のIEは、これが仕様となってしまっているため、再送信時にBODYを送信してくれない、という話題が前提にあります。

    それを念頭において、パケットをおっていくと・・

    ・接続確立

    ・クライアントからRequest送信と同時に、サーバ側のKeepAliveタイムアウトが発生

    ・ブラウザにタイムアウトのための切断が来る前にRequestAを送信しているため、ブラウザからみれば、接続を再利用してようとしている

    ・しかし、サーバ側も、クライアントからのRequestを受け取る前に接続している

    ・クライアントからみれば、Requestを送信した直後、[ACK]ではなく[FIN,ACK]が送られてきたため、再接続し、再送信(RequestB)を試みる

    ・ここで、冒頭の問題がありBODYが送られない

    と、いう流れだと判断しました。

    RequestAとRequestBは、POST内容が同じだったため、再送信と判断しました。

    実際には、このあと、SSOサーバーのKeepAliveタイムアウト値、APPサーバのKeepAliveタイムアウト値を確認し、それぞれブラウザより大きくして問題再現するか、までの確認が必要だと思っております。

    みなさまのおかげで勉強になりました。ありがとうございます!

    2014年5月1日 7:36