POSTリクエストで "Content-Length：0"なのはなぜですか？
顧客は、フォーム（10〜40を超えるフィールド）を送信するときに、POSTリクエストをContent-Length: 0とともに送信することがあります。
さまざまなブラウザとさまざまな場所でテストしましたが、エラーを再現できませんでした。顧客はInternet Explorer 7とプロキシを使用しています。
システム管理者に問題を彼らの側から見てもらうように依頼しました。プロキシなしでいくつかのテストを実行するなど。
その間（半年後でも答えはありません）他の誰かがContent-Length: 0リクエストで同様の問題を知っているかどうか興味があります。たぶん、大企業向けの特別なプロキシを備えたWindowsネットワーク内から。
Internet Explorer 7に既知の問題はありますか？プロキシシステムで？ Windowsネットワーク自体ですか？
GoogleはNTLM（およびそのような）認証のコンテキストでのみ表示しましたが、Webアプリケーションではこれを使用していません。たぶん、Windowsログインで顧客のネットワークでプロキシが動作する方法にあるのでしょうか？ （私はWindowsの専門家ではありません。推測するだけです。）
インフラストラクチャに関するこれ以上の情報はありません。
PDATE： 2010年12月に、これについて1人の管理者に通知することができました。こちらの回答からのリンク。連絡先は、プロキシによって引き起こされた別の問題も原因でした。それ以来、フィードバックはありません。そして、エラーメッセージはまだそこにあります。私は泣かないように笑っています。
PDATE 2：この問題は2008年半ばから存在しています。数か月ごとに顧客はいらいらし、できるだけ早く修正することを望んでいます。古いメールをすべて送信し、管理者に連絡して修正するか、さらにテストを実行するよう依頼します。 2010年12月に、1人の管理者に情報を送信することができました。フィードバックはありません。問題は修正されておらず、彼らが試してみたかどうかはわかりません。また、2011年5月に、顧客は再度書き込みを行い、これを修正することを希望しています。 2008年以降、すべての情報を持っている同じ人。
すべての答えをありがとう。ここでいくつかのコメントからわかるように、あなたは多くの人々を助けました。現実の世界は私にとってこのグロテスクなのは残念です。
更新3： 2012年5月、これを修正するために別の要求を受け取っていなかった理由が疑問でした（更新2を参照）。エラープロトコルを調べました。エラープロトコルは、発生するたびに（1日に約15回）この単一のエラーのみを報告します。 2012年1月末に停止しました。誰も何も言いませんでした。彼らは彼らのネットワークで何かをしたに違いない。すべては今大丈夫です。 2008年の夏から2012年1月まで。残念ながら、彼らが何をしたかはお伝えできません。
更新4： 2015年9月。Webサイトはいくつかのデータを収集し、それを顧客のメインWebサイトに配信する必要がありました。アカウントを持つAPIがありました。問題があるときはいつでも、たとえ問題が明らかに反対側にあったとしても、彼らは私たちに連絡しました。数週間、データを送信できません。アカウントはもう利用できません。再起動したため、サイトのデータを使用しているページはもう見つかりません。バグレポートには回答がなく、誰からも苦情はありません。彼らはちょうどこのプロジェクトを終了したと思います。
更新5： 2017年3月。APIは2015年夏に機能を停止しました。顧客はサイトへの支払いを継続しているようで、2017年2月にもアクセスしています。アーカイブ。彼らはもうデータを作成したり更新したりしないので、2012年1月の不思議な修正の後、このバグはおそらく再出現しないでしょう。しかし、これは誰かの問題でしょう。私は行きます。
Internet Explorerは、認証済みサイト（NTLM）から非認証サイト（匿名）に投稿されたフォームフィールドを送信しません。
これは、チャレンジ応答状況（NTLMまたはKerberosで保護されたWebサイト）の機能です。ここで、IEは、最初のPOST要求がすぐにHTTP 401 Authentication Required応答（チャレンジを含む）、および2番目のPOST要求（チャレンジへの応答を含む）のみが実際にこれらの状況ではIEはパフォーマンス上の理由から最初のリクエストでおそらく大きなリクエストボディをアップロードしません。コメントにその情報を投稿してくれた EricLaw に感謝します。
この動作は、HTTP POSTがNTLM認証（つまりイントラネット）ページから非認証（つまりインターネット）ページに作成されるたびに、または非認証ページがフレームセット。フレームセットページが認証されます。
回避策は、GETメソッドをフォームメソッドとして使用するか、認証されていないページが部分的に認証されたフレームセットなしで新しいタブ/ウィンドウ（お気に入り/リンクターゲット）で開かれるようにすることです。ウィンドウ全体の認証モデルが一致するとすぐに、IEはフォームのコンテンツの送信を再開します。
- 間違いなく関連： http://www.websina.com/bugzero/kb/browser-ie.html
- 関連する可能性がある： KB923155
- 完全な説明： IEInternalsブログ–チャレンジ/レスポンス認証と長さゼロの投稿
これは、MS-IEとサーバー側のNTLM認証フィルターで簡単に再現できます。 JCIFS（1.2。）、ストラット1。、およびXP-SP2上のMS-IE 6/7でも同じ問題があります。最終的に修正されました。それを補うためのいくつかの回避策があります。
フォームメソッドをPOST（デフォルト設定のstruts）からGETに変更します。小さなサイズのフォームを持つほとんどのページでは、うまく機能します。残念ながら、サーバー側にHTTPストリームで送信する50を超えるレコードがあります。 IEにはGET URL制限2038バイトがあります（パラメーター長ではなく、URL全体の長さ）。したがって、これは簡単な回避策ですが、私には適用できません。
POSTアクションの実行前にGETを送信します。これはMS-KBで推奨されていました。私のプロジェクトには多くのレガシー手順があり、適切なタイミングでリスクを取ることはありません。 MS-KBからの理解に基づいてフィルターレイヤーがGETを受信するときに追加の認証処理が必要であり、他のブラウザーの動作を変更したくないため、これを試したことはありません。 Firefox、Opera。
POSTがコンテンツ長ゼロで送信されたかどうかを検出します（フレームワークのヘッダープロパティハッシュ構造から取得できます）。その場合、DCまたはキャッシュからチャレンジコードを取得してNTLM認証サイクルをトリガーし、NTLM応答を期待します。 NTLM type2メッセージが受信され、セッションがまだ有効な場合、ユーザーを認証する必要はありませんが、POST content-lengthがゼロでない場合は、期待されるアクションに転送するだけです。ところで、これはネットワークトラフィックを増加させるでしょう。そのため、変更PLZを適用する前に、キャッシュライフタイム設定とSMBセッションsoTimeOut構成を確認してください。または、より簡単に、401-unauthorizedステータスをMS-IEに送信するだけで、ブラウザはPOSTリクエストを返信データと共に送信します。
MS-KBはKB-923155でホットフィックスを提供しました（評判番号が低いため複数のリンクを投稿できませんでした：{）が、機能していないようです。誰かが実行可能なホットフィックスをここに投稿しますか？ありがとう:)ここに参照用リンクがあります http://www.websina.com/bugzero/kb/browser-ie.html
システム上にまったく同じ問題を抱える顧客がいます。プロキシ/ファイアウォールを特定しました。 MicrosoftのIAS。 POST bodyを削除し、content-length：0を送信します。ただし、回避するためにできることはあまりありません。これはURLでユーザー名/パスワードなどを公開するため、GET要求を使用したいです。私たちのシステムにはほぼ7,000人のユーザーがいますが、問題のあるユーザーは1人だけで、Microsoft IASを使用しているのは1人だけです。
問題は、間にあるプロキシサーバーがHTTP 1.0を実装している可能性が高いことです
HTTP 1.0では、Content-Lengthヘッダーフィールドを使用する必要があります：（ セクション10.4を参照 ）
有効なContent-Lengthは、すべてのHTTP/1.0 POST要求で必要です。HTTP/ 1.0サーバーは、要求メッセージのコンテンツの長さを判別できない場合、400（不正な要求）メッセージで応答する必要があります。 。
プロキシに入る要求はHTTP 1.1であるため、Content-Lengthヘッダーフィールドを使用する必要はありません。通常、Content-Lengthヘッダーが使用されますが、常にではありません。 HTTP 1.1 RFC S. 14.1 からの次の抜粋を参照してください。
セクション4.4 の規則で禁止されていない限り、アプリケーションはこのフィールドを使用して、メッセージ本文の転送長を示す必要があります。ゼロ以上のContent-Lengthは有効な値です。
セクション 4.4 は、Content-Lengthが指定されていない場合にメッセージ本文の長さを決定する方法を説明しています。
そのため、プロキシサーバーにはContent-Lengthヘッダーが表示されません。ヘッダーがある場合、HTTP 1.0では絶対に必要です。したがって、要求が最終的にサーバーに到達するように0を想定しています。プロキシはHTTP 1.1仕様のルールを知らないため、Content-Lengthヘッダーがない場合の状況の処理方法を知らないことに注意してください。
リクエストでContent-Lengthヘッダーが指定されていることを100％確信していますか？サーバーが1.1であると見なしているため、セクション4.4で定義されている別の手段を使用している場合（1.0プロキシを知らないため）、説明されている問題が発生します。
おそらく、代わりにHTTP GETを使用して問題を回避することができます。
これはInternet Explorer 6の既知の問題ですが、私が知っている7の問題ではありません。 IE6のこの修正プログラムをインストールできます KB831167 修正プログラム。
あなたへのいくつかの質問：
- どのタイプのプロキシを知っていますか？
- リクエストで実際の本文が送信されているかどうかを知っていますか？
- 毎回一貫して発生しますか？それともたまにしか？
- リクエストで送信されたバイナリデータはありますか？データが\ 0で始まり、プロキシにバイナリデータのバグがある可能性があります。
ユーザーがISA NTLM認証を使用するプロキシを経由している場合、この問題のように聞こえますが、解決策が提供されています（ISAプロキシ）
http://support.Microsoft.com/kb/942638
POST本文を持たないPOST要求は、ISA Server 2006で公開されているWebサーバーに送信できます。
また、顧客のIE 11ブラウザにContent-Length: 0があり、期待されるPOSTコンテンツが含まれていません。 Firefox、またはChrome=予想されるコンテンツがリクエストに含まれていました。
原因は、顧客がHTTPS URLの代わりにHTTP URL（たとえば、http://...ではなくhttps://...）を使用しており、アプリケーションがHSTSを使用していることです。 IE 11には、HSTSによりリクエストがHTTPSにアップグレードされると、リクエストの内容が失われるというバグがあるようです。
お客様にhttps://...へのURLを修正してもらうと、コンテンツがPOST=リクエストに含まれ、問題を解決しました。
この段階で、これが実際にIE 11のバグであるかどうかは調査していません。
これらのリクエストは「顧客」からのものであると確信していますか？
これまでにボットでこの問題が発生しました。クロール中に発見したFORMタグ内のアクションURIに基づいて空のPOST=リクエストを送信することにより、「お問い合わせ」フォームのサイトをプローブすることがあります。
HTTPのContentLengthヘッダーの存在および可能な値は、HTTP（私は1/1と仮定）RFCで説明されています。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
HTTPでは、転送前にメッセージの長さが決定できる場合は必ず送信する必要があります
こちらもご覧ください：
Transfer-EncodingヘッダーフィールドとContent-Lengthヘッダーフィールドの両方を含むメッセージを受信した場合、後者を無視する必要があります。http ：//www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
メッセージにTransfer-Encodingヘッダーが含まれている可能性がありますか？
後の編集：また、RFCで使用される「SHOULD」は非常に重要であり、「MUST」と同等ではないことに注意してください。
3。この言葉、または「推奨」という形容詞は、特定の状況で特定の項目を無視する正当な理由が存在する可能性があることを意味しますが、別のコースを選択する前に完全な意味を理解し、慎重に検討する必要があります。参照： http://www.ietf.org/rfc/rfc2119.txt
curlは、HTTPプロキシを使用するように構成されている場合、PUT/POSTでContent-Length: 0要求を送信します。プロキシへの最初の不正なPUT/POSTリクエストの場合に必要なバッファリングを克服するのはコツです。 GET/HEADリクエストの場合curlは単にクエリを繰り返します。 PUT/POSTのスキームは次のようなものです：
PUT/POSTを0に設定して最初のContent-Lengthリクエストを送信します。答えを得る。 HTTPステータスコード407は、プロキシ認証を使用する必要があることを意味します。送信リクエストのプロキシ認証用のヘッダーを準備します。
プロキシ認証用の入力済みヘッダーと実際のデータを含むリクエストをPOST/PUTに再度送信します。
匿名モードとNTLMモードで（異なるポートで）同じWebサイトを使用しているお客様がいました。このケースでは、401はhttp最適化に使用されるRiverbed Steelheadアプリケーションに関連していることがわかりました。その方向を示す最初の信号は、X-RBT-Optimized-Byヘッダーでした。問題はGratuitous 401機能でした：
この機能は、要求ごとの認証と接続ごとの認証の両方で使用できますが、要求ごとの認証で使用すると最も効果的です。リクエストごとの認証では、サーバーがクライアントにオブジェクトを提供する前に、すべてのリクエストをサーバーに対して認証する必要があります。ただし、ほとんどのブラウザは認証を必要とするサーバーの応答をキャッシュしないため、GETリクエストごとに1回のラウンドトリップが無駄になります。 Gratuitous 401を使用すると、クライアント側のSteelheadアプライアンスはサーバーの応答をキャッシュし、クライアントが認証ヘッダーなしでGETリクエストを送信すると、「401 Unauthorized」メッセージでローカルに応答し、ラウンドトリップを節約します。 HTTPモジュールは、実際の認証自体には関与しないことに注意してください。 HTTPモジュールが行うことは、サーバーが1回のラウンドトリップを無駄にすることなく認証を必要とすることをクライアントに通知することです。
KB821814 のMicrosoftの修正プログラムは、Content-Lengthを0に設定できます。
この資料に記載されている修正プログラムは、Wininet.dllのコードを次のように変更します。
- POSTリクエストでRESET条件を検出します。
- 転記するデータを保存します。
- コンテンツの長さを0に設定してPOSTリクエストを再試行します。これにより、リセットが発生しなくなり、認証プロセスが完了します。
- 元のPOST要求を再試行してください。
Googleはこれを、https接続がキープアライブタイムアウトに達し、サーバーに再接続した後のIE（とにかくバージョン）バグ）としても表示します。 IE httpsの下。