問題タブ [http-status-code-100]

Java Servlet API (HttpServletResponse) を使用してリクエスト全体を処理した後、「100 Continue」HTTP ステータス コードを送信し、後で他のステータス コードを送信することはできますか?

APIはサポートしていないようですが、決定的な「いいえ」の答えは見つかりません。

私は ASP.NET MVC を使用して REST API を実装していExpect: 100-continueますが、投稿本文を含む要求の要求ヘッダーの形で小さな障害が発生しました。

RFC 2616は次のように述べています。

「100-continue」期待値を持つ Expect リクエスト ヘッダー フィールドを含むリクエストを受信すると、オリジン サーバーは 100 (Continue) ステータスで応答して入力ストリームからの読み取りを続行するか、最終ステータス コードで応答する必要があります。オリジン サーバーは、100 (Continue) 応答を送信する前に、要求本文を待機してはなりません。最終ステータス コードで応答する場合、トランスポート接続を閉じるか、残りの要求を読み込んで破棄し続けることができます。最終ステータス コードを返す場合、要求されたメソッドを実行してはなりません。

これは、リクエストに対して2 つの応答を行う必要があるように思えます。つまり、すぐに HTTP 100 Continue 応答を送信してから、HttpContext.Request.InputStream要求を終了せずに元の要求ストリーム (つまり ) から読み取りを続行し、最後に結果を送信する必要があります。ステータス コード (議論のために、それが 204 No Content の結果であるとしましょう)。

したがって、質問は次のとおりです。

1. 要求に対して 2 つの応答を行う必要があるという仕様を正しく読んでいますか?
2. ASP.NET MVC でこれを行うにはどうすればよいですか?

wrt (2) 入力ストリームの読み取りに進む前に、次のコードを使用してみました...

...しかし、最終的な 204 ステータス コードを設定しようとすると、エラーが発生します。

System.Web.HttpException: HTTP ヘッダーが送信された後、サーバーは状態を設定できません。

クライアントソフトウェアから要求を受信するASP.NETアプリケーションがあり、要求ヘッダーに「要求100-続行」が含まれています。

他のヘッダーを使用してユーザーを認証（または認証しない）し、状態（100は明らかに認証されたまま）または適切なエラーメッセージに応じて適切な応答を送信できるように、request-100ヘッダーに対するIIS自動応答をオーバーライドしたい。

特定のクライアントからの大きな POST ファイルのアップロードを受け入れる PHP Web アプリケーションに取り組んでおり、ファイルが HTTP/1.1 100 を使用してアップロードされる前に、(サイズだけでなく、さまざまなヘッダーやその他の要因に基づいて) これらのアップロードを受け入れまたは拒否したいと考えています。継続する。

HTTP/1.1 仕様 8.2.3からのいくつかの簡単な背景:

100 (Continue) ステータス (セクション 10.1.1 を参照) の目的は、リクエスト本文を含むリクエスト メッセージを送信しているクライアントが、オリジン サーバーがリクエストを受け入れるかどうかを (リクエスト ヘッダーに基づいて) 判断できるようにすることです。クライアントがリクエストボディを送信する前。場合によっては、サーバーが本文を確認せずにメッセージを拒否する場合、クライアントが本文を送信することは不適切または非常に非効率的である可能性があります。

問題は、Apache がクライアントから Expect: 100-continue を認識し、PHP が処理を開始する前に 100 Continue を返し、ファイルのアップロードを受け入れることです...ただし、Expect: 100-continue の直後に処理を開始するには、PHP が必要です。これが可能かどうかわからないので、2つの質問があります。

1. Expect: 100-continue の直後に PHP の処理を​​開始することは可能ですか?
2. そうでない場合、良い代替手段は何ですか?

私は現在、クライアントが最初に POST と同じヘッダーを持つ HEAD リクエストを送信するように指定して、100 の継続をエミュレートすることを考えています。その後、webapp は、POST またはエラー コードを続行するための応答を返すことができます。他の提案は大歓迎です！

注：クライアント側ではlib_neonを使用し、サーバー側ではTomcatとサーブレットAPIを使用しています。

問題は次のとおりです。クライアントがコンテンツを入れたい場合、「Expect：100-continue」ヘッダーを使用してPUTリクエストを実行し、Tomcatはステータス100 Continueを返すだけでそれを処理し、その後、クライアントはリクエストの残りの部分の送信を開始します。 、そしてそれは私たちのカスタムフィルターによって処理され、しばしば通過しません（例えば、ユーザーが許可されていないか、大きすぎるファイルを入れようとしたり、ユーザーの制限を超えたりするなど）。フィルタはすぐにエラー応答を送信しますが、クライアントは完全な要求本文がコミットされた場合にのみ応答を読み取ります。

一部のチェックが失敗し、この動作がtomcatにハードコードされている場合、100続行ステータスの代わりに手動で何かを送信することは不可能のようです。不可能な場合にリクエスト本文をアップロードしない他の方法はありますか？

QueryStringファイルを受け取ってクライアントにストリーミングする ASP.Net Web ページを作成しました。ファイルは SQL Server データベースに保存されます。開発中に Web サイトをローカルで実行している場合、すべてがうまく機能します。サーバーから本番環境で実行すると、Firefox からファイルを取得できますが、Chrome からは取得できません。Chromeで私は得るError 100 (net::ERR_CONNECTION_CLOSED): Unknown error.

これが に関連している可能性があると言及している他の投稿を参照してくださいContent-Length。そのため、ここで何か他のことが起こっているに違いないと思います。

提案/ヒントをありがとう。

これが私のコードです：

私のヘッダーは次のとおりです。

多くのライブラリにはExpect: 100-continue、デフォルトですべてのHTTP1.1POSTおよびPUTリクエストが含まれています。

データをすぐに送信するコストが100継続のラウンドトリップを待つよりも少ないことがわかっているリクエスト、つまり短いリクエストで、クライアント側の100継続メカニズムを削除することで、知覚されるレイテンシを減らすつもりです。

Expect: 100-continueもちろん、私はまだHTTP 1.1の他のすべての優れた機能が必要なので、ヘッダーを強制終了したいだけです。私には2つの選択肢があります：

• 期待ヘッダーを完全に削除するか、
• 空のexpectヘッダーを送信します。Expect:\r\n

2つの間に違いはありますか？

どちらか一方のために壊れるかもしれないソフトウェアはありますか？

netty 4 (netty-all-4.0.9.jar を使用) サービスをインスタンス化し、3 つの ChannelHandler オブジェクトを追加してチャネルを初期化しました。

HTTP PUT私のサーバーにファイルをカールさせてテストすると、ヘッダーが送信さMyHandler.channelReadれたリクエストに対してすぐに呼び出されないことがわかりました（カールはサーバーが応答Expect: 100-continueするのを待っています100 Continue.これは、ハンドラーがHTTP/1.1 100 Continueclient (curl) を使用して、ファイルの実際のアップロードをすぐに開始します。

興味深いことに、この問題をさらにデバッグすると、実際の本文がアップロードされた直後 (最初のバイトが受信された直後) にtelnetaが呼び出されることがわかります。channelRead

PUT「Expect: 100-continue」ヘッダーを使用してリクエストを適切に処理し、100 Continueレスポンスをすぐにトリガーする方法に関するヒントはありますか?

libcurl (c++) ライブラリを使用して、IIS 7.5 サーバーに要求を送信しています。トランザクションは一般的な SOAP

Web サービスです。すべて正常に動作しています。リクエストは「Expect 100-continue」フラグを送信し、サーバーは 100-continue で応答し、その後すぐに 200 ok コードと Web サービス応答を返します。

しかし、ときどき、クライアントは 100 継続メッセージを受信し、その後、別の 100 コードを受信します。これにより、サーバー 100 コードの直後に最終ステータス コードが期待されるため、クライアントはエラーを報告します。私は W3C HTTP1.1 プロトコルを読みました:

100 (Continue) 応答を送信するオリジン サーバーは、トランスポート接続を途中で終了しない限り、要求本文が受信されて処理されると、最終的に最終ステータス コードを送信する必要があります。

「最終的に」という言葉は、私を道に迷わせます。サーバーが最終ステータス コードの後に​​数 100 個のコードを送信することは可能/一般的ですか?

誰かが以前にこの問題に直面したことがある場合は、libcurl で複数の 100 応答コードを処理する方法について説明してもらえますか?

前もって感謝します