5

ApiControllerHTTP のステータス コード 307 を介してリダイレクトすることにより、POST 要求に応答する があります。これは、ヘッダーからの情報のみを使用して行われるため、このアクションでは要求の本文は必要ありません。このアクションは次と同等です。

public HttpResponseMessage Post() {
    var url;
    // Some logic to construct the URL
    var response = new HttpResponseMessage(HttpStatusCode.TemporaryRedirect);
    response.Headers.Location = new System.Uri(url);
    return response;
}

これは簡単ですが、改善したい点が 1 つあります。リクエストの本文には大量のデータが含まれる可能性があるため、HTTP ステータス コード 100 を利用して、このリクエストをより効率的にしたいと考えています。コントローラーをそのまま使用すると、会話は次のようになります。

> POST /api/test HTTP/1.1
> Expect: 100-continue
> ...

< HTTP/1.1 100 Continue

> (request body is sent)

< HTTP/1.1 307 Temporary Redirect
< Location: (the URL)
< ...

リダイレクト アクションではリクエスト ボディは必要ないため、会話を次のように短縮できるようにしたいと考えています。

> POST /api/controller HTTP/1.1
> Expect: 100-continue
> ...

< HTTP/1.1 307 Temporary Redirect
< Location: (the URL)
< ...

これを達成する方法を調査するために 1 日の大部分を費やしましたが、解決策を思いつくことができませんでした。私の研究では、次のことを学びました。

  • ApiControllerのアクションが実行されるとき、100 Continueはすでに送信されています。
  • がApiController作成された時点で、100 Continueはすでに送信されています。
  • HttpApplicationのPreRequestHandlerExecuteイベントがトリガーされたときに、100 Continue応答が送信されていません。
  • がDelegatingHandler実行されると、100 Continueはすでに送信されています。

これに基づいて、これまでに思いついた最善の解決策は、問題の がリクエストの受信者である場合に、 onHttpModuleを使用してレスポンスをオーバーライドするを作成することです。ただし、これはいくつかの理由 (コードの分離、Web API のパラメーター バインディングを利用しない、および の追加ロジックをバイパスする) により、理想的なソリューションとはほど遠いものです。RouteDataRequestContextApiControllerAuthorizeAttributeApiController

これにはもっと良い解決策があるように思えますがExpect: 100-continue、Web API アプリケーションでヘッダーを適切に処理する方法に関する情報はほとんど見つかりませんでした。ヘッダーを適切に処理するためにこれを実装する最も簡単な方法は何でしょうか?ApiControllerExpect: 100-continue

4

2 に答える 2

1

...この最適化が本当に必要ですか?

IIS 6 を使用している場合は、IIS 5 互換モードに移行し、ReadRawData/SendRawData ISAPI フィルターを作成しようとしています。ISAPI 拡張機能は、私の回答の下にある理由から問題外です。(IIS 5 以下を使用している場合は、神があなたの魂を憐れんでくださいますように)

IIS 7 以降を使用している場合は、IIS ネイティブ モジュールを作成するだけで済む場合があります。

Web API は ASP.NET 内に存在するため、コントローラーが関与するまでに応答が既に送信されているというあなたの考えは正しいです。この応答は IIS コアによって処理されています。

いくつかの軽い読み物

HTTP.SYS IIS と 100 継続

デビッド・ワン

「400 Bad Request」や Kernel Response Cache Hit のような「100 continue」は、HTTP.SYS がユーザー モードに何も通知せずにカーネル モードで透過的に処理するという点で特別です。出力 - 応答出力のみを生成でき、応答出力の結果は表示されません。したがって、ISAPI 拡張機能は、「100 continue」または「100 continue」応答を生成する要求と対話してそれらを抑制することはできません。

IIS6 では、HTTP.SYS のこれらの透過的な要求処理にユーザー モード処理を挿入する唯一の方法は、IIS5 互換モードで実行し、ReadRawData/SendRawData ISAPI フィルターを使用することです。ReadRawData は、HTTP.SYS に生データをネットワークからユーザー モードに渡して、そのユーザー モード出力を HTTP 要求に解析してキューに配置する前にフィルタリングします。

もちろん、この方法は、アプリケーション プールとプロセスの分離を使用して IIS6 を実行するという目的を完全に無効にします (このフィルタリング ユーザー モード プロセスで 1 回失敗すると、サーバー全体が停止します)。 ..

参考: このアプローチは、Vista Server/IIS7 では機能しません。HTTP.SYS は、解析前にフィルタリングのためにネットワークから生データをユーザー モードに渡さなくなります。そのため、ユーザー モード コードは、自動 "100 continue" をトリガーする要求が発生したことを知ることができなくなります。

編集

ハッキングされた Http Web リクエストは 100 継続を期待

于 2014-10-24T01:28:07.213 に答える
0

同じソリューションでブラウザーを別のコントローラーにリダイレクトしていると思います。リダイレクトの代わりに、元の URL アドレスで直接リクエストを処理できます。この方法では、クライアントはリダイレクトされることなく、リクエストを 1 回だけ送信する必要があります。

これを実装する 1 つの方法はIHttpControllerSelector、要求ヘッダーに基づいて正しいコントローラーに要求を割り当てる独自のコントローラーを作成することです。

カスタム セレクターを特定のルートにのみ割り当てたい場合は、次の SO の質問を確認することをお勧めします: ASP.NET Web API custom IHttpControllerSelector for a single route

于 2014-10-27T10:06:56.537 に答える