56

Content-Length: 0顧客は、フォーム (10 から 40 以上のフィールド) を送信するときに、POST 要求を送信することがあります。

さまざまなブラウザーでさまざまな場所からテストしましたが、エラーを再現できませんでした。お客様は Internet Explorer 7 とプロキシを使用しています。

システム管理者に彼らの側から問題を見てもらうよう依頼しました。プロキシなしでいくつかのテストを実行するなど.

それまでの間(半年後、まだ回答がありません)、他の誰かがContent-Length: 0リクエストに関する同様の問題を知っているかどうか知りたいです。おそらく、大企業向けの特別なプロキシを使用して、Windowsネットワーク内から.

Internet Explorer 7 に既知の問題はありますか? プロキシシステムとは?Windows ネットワークそのもの?

Google は NTLM (およびそのような) 認証のコンテキストでのみ何かを示しましたが、Web アプリケーションではこれを使用していません。Windows ログインを使用する顧客のネットワークでプロキシが動作する方法に問題があるのでしょうか? (私は Windows の専門家ではありません。推測です。)

インフラストラクチャに関するこれ以上の情報はありません。

更新: 2010 年 12 月に、これについて 1 人の管理者に通知することができました。ここの回答からのリンク。連絡は、プロキシによって引き起こされた別の問題によるものでもありました。それ以来、フィードバックはありません。エラーメッセージはまだ残っています。泣かないように笑っている。

更新 2:この問題は 2008 年半ばから存在しています。数か月ごとに顧客はイライラしており、できるだけ早く修正することを望んでいます。古い電子メールをすべて再度送信し、管理者に連絡して修正するか、さらにテストを実行するよう依頼します。2010 年 12 月に、1 人の管理者に情報を送信することができました。フィードバックはありません。問題は修正されておらず、彼らが試したかどうかもわかりません. そして 2011 年 5 月に、顧客は再び書き込みを行い、これを修正したいと考えています。2008 年以降のすべての情報を持っているのは同じ人物です。

すべての答えをありがとう。ここのいくつかのコメントからわかるように、あなたは多くの人々を助けました. 残念ながら、現実の世界は私にとってこれほどグロテスクです。

更新 3: 2012 年 5 月、なぜこれを修正する別の要求を受けなかったのか疑問に思っていました (更新 2 を参照)。エラー プロトコルを調べたところ、発生するたびにこの 1 つのエラーしか報告されませんでした (1 日に約 15 件)。2012 年 1 月末に停止しました。誰も何も言いませんでした。彼らはネットワークで何かをしたに違いありません。今はすべて問題ありません。2008 年の夏から 2012 年 1 月まで。

更新 4: 2015 年 9 月。Web サイトはデータを収集し、それを顧客のメイン Web サイトに配信する必要がありました。アカウント付きのAPIがありました。問題が明らかに反対側にある場合でも、問題が発生したときはいつでも、彼らは私たちに連絡してくれました。ここ数週間、データを送信できません。アカウントはもう利用できません。彼らはリニューアルし、私たちのサイトのデータを使用したページを見つけることができなくなりました。バグレポートには回答がなく、誰も苦情を言いません。彼らはこのプロジェクトを終了したばかりだと思います。

更新 5: 2017 年 3 月。API は 2015 年の夏に動作を停止しました。顧客はサイトの料金を支払い続けているようで、2017 年 2 月にまだアクセスしています。アーカイブとして使用していると思います。彼らはもうデータを作成したり更新したりしないので、このバグはおそらく 2012 年 1 月の不可解な修正の後は再発しないでしょう。しかし、これは他の誰かの問題でしょう。私は行きます。

4

13 に答える 13

15

これは、MS-IE とサーバー側の NTLM 認証フィルターで簡単に再現できます。XP-SP2 のJCIFS (1.2. )、struts 1.、および MS-IE 6/7 で同じ問題が発生します。最終的に修正されました。それを補うためのいくつかの回避策があります。

  1. フォームメソッドを POST (struts のデフォルト設定) から GET に変更します。小さなサイズのフォームを含むほとんどのページでは、うまく機能します。残念ながら、HTTPストリームでサーバー側に送信するレコードが50を超える可能性があります。IE には 2038 バイトの GET URL 制限があります (パラメーターの長さではなく、URL 全体の長さ)。したがって、これは簡単な回避策ですが、私には適用できません。

  2. POST アクションの実行前に GET を送信します。これは MS-KB で推奨されていました。私のプロジェクトには多くのレガシー手順があり、適切なタイミングでリスクを負うことはありません。MS-KB からの私の理解に基づいて、GET がフィルター層によって受信されたときにまだ追加の認証処理が必要であり、Firefox、Opera などの他のブラウザーで動作を変更したくないため、これを試したことはありません。

  3. content-length が 0 の POST が送信されたかどうかを検出します (フレームワークのヘッダー プロパティ ハッシュ構造から取得できます)。その場合は、DC またはキャッシュからチャレンジ コードを取得して NTLM 認証サイクルをトリガーし、NTLM 応答を期待します。NTLM タイプ 2 メッセージが受信され、セッションがまだ有効な場合、実際にユーザーを認証する必要はありませんが、POST content-length がゼロでない場合は、期待されるアクションに転送するだけです。ところで、これによりネットワーク トラフィックが増加します。そのため、plz の変更を適用する前に、キャッシュの有効期間の設定と SMB セッションの soTimeOut の設定を確認してください。または、もっと単純に、MS-IE に 401-unauthorized ステータスを送信するだけで、ブラウザは POST リクエストにデータを返信します。

  4. MS-KB は KB-923155 のホット フィックスを提供しています (レピュテ​​ーション番号が低いため、複数のリンクを投稿できませんでした :{ ) が、機能していないようです。誰かが実行可能なホットフィックスをここに投稿しますか? ありがとう:)参照用のリンクは次のとおりです。 http://www.websina.com/bugzero/kb/browser-ie.html

于 2010-04-13T06:49:39.187 に答える
6

私たちのシステムには、まったく同じ問題を抱えた顧客がいます。プロキシ/ファイアウォールにピンで留めました。マイクロソフトの IAS。POST 本文を削除し、content-length: 0 を送信しています。ただし、回避するためにできることは多くなく、URL 文字列でユーザー名/パスワードなどを公開するため、GET 要求を使用したいと考えています。私たちのシステムには約 7,000 人のユーザーがいますが、問題を抱えているのは 1 人だけです... Microsoft IAS を使用しているのは 1 人だけなので、これに違いありません。

于 2009-07-01T09:23:13.990 に答える
3

これは Internet Explorer 6 では既知の問題ですが、私が知っている 7 ではそうではありません。この修正プログラムは、IE6 KB831167修正プログラムにインストールできます。

詳細については、こちらをご覧ください。

あなたへのいくつかの質問:

  • プロキシの種類を知っていますか?
  • リクエストで送信された実際の本文があるかどうか知っていますか?
  • それは毎回一貫して起こりますか?それともたまにだけ?
  • リクエストで送信されたバイナリ データはありますか? データが \0 で始まり、プロキシにバイナリ データのバグがある可能性があります。
于 2009-03-11T19:49:18.090 に答える
2

ユーザーが NTLM 認証を使用する ISA プロキシを経由している場合は、この問題のように聞こえます。解決策が提供されています (ISA プロキシへのパッチ)。

http://support.microsoft.com/kb/942638
POST 本文を持たない POST 要求が、ISA Server 2006 で公開されている Web サーバーに送信される場合がある

于 2010-06-30T15:32:15.157 に答える
1

これらの要求は「顧客」からのものであると確信していますか?

以前にボットでこの問題が発生しました。クロール中に発見した FORM タグのアクション URI に基づいて空の POST リクエストを送信することで、「お問い合わせ」フォームのサイトを調査することがあります。

于 2008-11-30T01:28:03.510 に答える
1

HTTP での ContentLength ヘッダーの存在と可能な値は、HTTP (1/1 と仮定します) RFC で説明されています。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13

HTTP では、転送前にメッセージの長さを判断できる場合はいつでも送信する必要があります (SHOULD)。

以下も参照してください。

Transfer-Encoding ヘッダー フィールドと Content-Length ヘッダー フィールドの両方を含むメッセージを受信した場合、後者は無視する必要があります。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

メッセージに Transfer-Encoding ヘッダーが含まれている可能性がありますか?

後で編集: また、RFC で使用されている「SHOULD」は非常に重要であり、「MUST」と同等ではないことに注意してください。

3. SHOULD この単語、または形容詞「RECOMMENDED」は、特定の状況では特定の項目を無視する正当な理由が存在する可能性があることを意味しますが、別のコースを選択する前に、完全な意味を理解し、慎重に検討する必要があります。 参照: http://www.ietf.org/rfc/rfc2119.txt

于 2008-11-30T09:03:03.390 に答える
1

匿名および NTLM モード (異なるポート) で同じ Web サイトを使用している顧客がいました。私たちの場合、401 は http 最適化に使用される Riverbed Steelhead アプリケーションに関連していることがわかりました。その方向性を示す最初のシグナルは、X-RBT-Optimized-By ヘッダーでした。問題は Gratuitous 401 機能でした。

この機能は、リクエストごとの認証と接続ごとの認証の両方で使用できますが、リクエストごとの認証で使用すると最も効果的です。リクエストごとの認証では、サーバーがクライアントにオブジェクトを提供する前に、すべてのリクエストがサーバーに対して認証される必要があります。ただし、ほとんどのブラウザーは、認証を必要とするサーバーの応答をキャッシュしないため、GET 要求ごとに 1 回のラウンドトリップが無駄になります。Gratuitous 401 を使用すると、クライアント側の Steelhead アプライアンスはサーバーの応答をキャッシュし、クライアントが認証ヘッダーなしで GET 要求を送信すると、「401 Unauthorized」メッセージでローカルに応答するため、往復が節約されます。HTTP モジュールは、実際の認証自体には関与しないことに注意してください。

于 2014-09-15T06:25:17.730 に答える
0

また、Googleは、https接続がキープアライブタイムアウトに達してサーバーに再接続した後、これをIE(とにかく一部のバージョン)のバグとして示しています。解決策は、httpsでIEのキープアライブを使用しないようにサーバーを構成しているようです。

于 2008-11-30T07:43:17.450 に答える
0

KB821814に対する Microsoft のホットフィックスは、Content-Length を 0 に設定できます。

この記事で説明する修正プログラムは、Wininet.dll のコードを次のように変更します。

  • POST 要求で RESET 条件を検出します。
  • 転記するデータを保存します。
  • コンテンツの長さを 0 に設定して POST 要求を再試行します。これにより、リセットが発生するのを防ぎ、認証プロセスを完了することができます。
  • 元の POST 要求を再試行します。
于 2009-11-17T23:38:48.740 に答える