Apache 2.4 の KeepAlive がフォームの送信を妨害する

Apache 2.4 の KeepAlive がフォームの送信を妨害する

サーバーを、Apache 2.4.10 (以前は 2.2) と PHP 5.6 を含む Debian Jessie にアップグレードしました。

現在、SSL サイトは、IE11 および iPad Safari (デスクトップ Safari については不明) で、状況によってはフォームを送信しません。Firefox と Chrome はどちらも問題ありません。失敗すると、IE で「このページを表示できません」という IE エラー ページが表示されます。念のため言っておきますが、サイトにアクセスしてフォームを確認することはできますが、フォームの送信が失敗します。

これは何らかの形で KeepAlive と SSL に関連しています。SSL VirtualHost で KeepAlive をオフにすると、問題は解消されます。(SNI を使用していますが、エラーが表示されるサイトの 1 つは最初の SSL サイトです)。私は mpm-itk を使用しています (アップグレード前も使用していました)。

IE11 (Windows 7 上) では、次の場合に発生します。 * SSL (HTTPS) * Apache KeepAlive オン、KeepAliveTimeout 5 (デフォルト) * ファイルアップロード付きのフォーム (enctype=multipart/form-data の場合) * ファイルが実際に提供された場合にのみ発生します (ファイルがなくても他のフィールドがあっても問題ありません。1 バイトのファイルでも失敗しますが、ファイル サイズには依存しません)。 * フォームを表示してから 60 秒以内にアップロードが開始された場合のみ (つまり、[送信] を押す前に 60 秒放置しても問題ありません)

何が失敗したのか、手がかりはありません。サーバー ログには、サーバーに再度接続したことを示すものは何もありません。エラーはすぐに発生します。IE デバッガーには、ネットワーク ページの結果列に「(中止)」と表示され、「ナビゲーションが発生しました: ファイル: dnserror.htm」と表示される以外は何も表示されません。これは、表示されているページだと思いますが、名前にもかかわらず、DNS エラーは発生していません。送信ボタンを押しても、Fiddler にネットワーク トラフィックは表示されません。Windows イベント ビューアーには、関連するものはありません。これが最も奇妙なことです。試行すらしていないようです。

Apache 2.4 の場合、ここで推奨されているように SSL を設定しました。https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.10&openssl=1.0.1k&hsts=no&profile=intermediateCiperSuite は 2.2 セットアップから変更されていませんが、OCSP ステーピングがオンになっています。2.4 の主な変更点は TLS1.2 です (ただし、Fidler はこれをダウングレードしたと思うので、それが原因である可能性は低いです)。HSTS はオンになっていますが、以前はオンでした。SSLLabs はこのサイトに A+ 評価を与えており、エラーは示されていません。

KeepAliveTimeout を 60 に変更し、古い BrowserMatch を戻してみました。マイクロソフト。「 nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 および BrowserMatch 」。マイクロソフト。「実験として ssl-unclean-shutdown を試してみましたが、これは確かに効果があると思います。つまり、最初の試行の後は機能します。しかし、新しく起動したブラウザからの最初のアクセスは依然として失敗します。これは、SSL ネゴシエーションが終わるまでブラウザを判別できないため、その時点では手遅れですが、その後はブラウザにさらに情報があるためでしょうか? また、このプロセスを 60 秒以内に実行できない可能性があり、その場合は 2 回目はとにかくそれで問題ありません。

問題を実証する小さなテスト サイトを作成しました。https://iet.davidearl.ukテストケース専用の自己署名証明書があるため、最初にアクセスしたときに証明書の警告が表示されますが、問題が発生する実際のサイトではそうではありません。テストケースでサーバー側が行うことは、送信されたファイルのファイル名をエコーすることだけです。それ以外は、HTML ソースがすべてです。

iPad では、問題はさらに悪化しているようです。フォームをまったく送信できないようです (ファイルのアップロードの有無にかかわらず、フォームは正常に表示されます)。フォームの構成によっては、ハングアップしたり、内部でエラー ページ (「ネットワーク接続が失われたため、Safari はページを開けません」) が生成されたりすることもあります。ただし、60 秒待ってから送信ボタンを押すと、正常に動作するという共通点もあります。ただし、PC 用の Safari の古いバージョン (5.1.7) は問題なく動作します。

Windows 7 (の別のコピー) 上の IE9 は、iPad Safari のように動作します。フォームを表示してから 60 秒待たないと、ハングアップします。Windows 10 上の Microsoft Edge と Surface RT タブレット上の IE も、IE11 と同じように失敗するようです。また、サーバーにアクセスする PHP "file_get_contents("https..." が、以前は即座に動作していたのに、成功するまで 60 秒間ハングアップし続けるケースも確認しました。

http : // superuser.com/questions/516030/apache-2-4-on-windows-responds-slowly-hangs-when-serving-some-dynamic-pages を試しましたが、変化はありませんでした。これはおそらく関連しているのでしょうが、彼らの場合、KeepAlive Off は効果がありません。サーバーのファイアウォールを一時的にオフにしても変化はありません: http : // serverfault.com/questions/678009/windows-8-ie-10-tls-handshake-errors-to-apache-2-2-on-centos-6-6 SSLCipherSuite の順序を変更して、ECDHE-RSA-AES128-SHA256 をリストのより上位に配置するようにしました (ここで提案されているように: http : // serverfault.com/questions/677338/why-is-internet-explorer-11-unable-to-connect-to-https-sites-when-tls-1-2-is-ena )。インターネットのプロパティ > コンテンツで SSL 状態をクリアしても変化はありません。

明らかに、KeepAlive と SSL に関連する、一般的ではない問題がありますが、それが何なのかわからず、原因を突き止める手がかりもありません。徹底的に検索しても、役に立つ情報は何も得られませんでした。

答え1

私もまったく同じ問題に遭遇しました (この問題で頭を悩ませた日が何日もありました)。

結局、mpm-itk のバグであることが判明しました (cf.http://lists.err.no/pipermail/mpm-itk/2015-9月/thread.html)。このバグは昨日リリースされた最新バージョンで修正されました。

この新しいバージョンは以下からダウンロードできます。http://mpm-itk.sesse.net/ただし、ソースから自分でコンパイルする必要があります。README ファイルの指示に従えば、非常に簡単です。

答え2

質問ありがとうございます!そしてシビデスク答えは、こちらです。私も ITK を使用しています (なぜもっと多くの人が使用しないのかはわかりません。仮想ホスト間の権限の分離が非常に便利だからです)。

私はこのバグを潰すために再コンパイルしたくありませんでした。いつかそれが Jessie に取り入れられ、apt-get魔法のように修正されるだろうと信じたいのです。しかし、私のクライアントはそれまで待てません!

IE では、特定のバージョンの jQuery で他のバージョンよりもこの問題が発生することが多いことに気付きました。そこで、使用している jQuery バージョンに戻すことで、問題の半分は解決しました。しかし、Safari では依然として問題が残っていました。機能することもあれば、何も表示されずに失敗することもありました。

これを機能させる方法は、Apache 構成setenvif.confファイルを編集して次の内容を含めることでした。

BrowserMatch "Mac OS X" nokeepalive

このアイデアは他の場所で評価されるべきである

この方法では、Mac ユーザーのキープアライブがオフになります。これによって Mac ユーザーの作業が少し遅くなることは間違いありませんが、UX が損なわれたり、動作しなくなったりするよりはましだと思います。

関連情報