問題タブ [ihttphandler]

Paul Johnson の Web Widgetsページの手順を使用して、独自のカスタム ウィジェットを作成しました。ただし、IIS 6.0 に展開していたため、IIS 7.0 の構成管理オプションは IIS 6.0 では使用できなかったため、推奨される web.config の変更を利用してページをレンダリングしました。

ウィジェットは、VS 2008 でのデバッグ時に正しくレンダリングされます。ただし、IIS 6.0 を実行している Windows 2003 Server にファイルと更新された web.config がデプロイされ、アドレスが参照されると、レンダリングされるエラーは「ページが見つかりません」です。

開発マシンは Windows Vista マシンですが、VS 2008 はデバッグ用に Vista の IIS 7.0 ではなく独自の内部 Web サーバーを使用しているため、これが問題になるとは思いませんでした。

この問題をデバッグするための助けをいただければ幸いです。

既存の .aspx ページが要求を処理するように IHttpHandler を作成する適切な方法は何ですか? .aspx ファイルを IHttpHandler にコンパイルして、要求を処理できるようにしたいと考えています。PageParser.GetCompiledPageInstance メソッドがありますが、ドキュメントには、コードから直接使用するためのものではないと記載されています。apsx ファイルを自動的に転送したり、RewritePath を実行したりできることはわかっていますが、ハンドラーへのオブジェクト参照が必要です。

*.jpgサーバー上のファイルに送信されるすべてのリクエストをキャプチャしたいと考えています。そのために、コードが次のような HttpHandler を作成しました。

これをコンパイルし、Web アプリケーションのBinディレクトリに参照として追加した後、web.configファイルに以下を追加しました。

次に、IIS の設定も変更し、拡張機能Home Directory -> Application Configurationを追加しました。aspnet_isapi.dll.jpg

Handler で、C ドライブに作成しているログ ファイルに何かを書き込もうとしましたが、ログ ファイルに書き込めず、バグを見つけることができません。

Image Type を処理するための IHttpHnalder の良い例を誰でも提供できますか。サーバーでホストされている画像のサイズを変更したい

ASP.NET の HttpHandler とは何ですか? なぜ、どのように使われるのですか？

MVC と WebForms の両方の Web アプリで使用できるコンポーネントを作成していますが、HttpContext の処理方法の違いを処理する方法がわかりません。

私のコンポーネントには、カスタム IHttpHandler (WebForms 用) またはカスタム ActionResult (MVC 用) が含まれています。

だから私はいくつかの質問があります：

• モデルを壊さずに MVC で IHttpHandler を使用する方法はありますか?
• 両方で機能するコードを作成しようとしているときに HttpContext.Current を使用することは許容されますか? 私には少し力ずくのように思えますが (理由はわかりません)、別の方法として、HttpContext と ControllerContext の間の抽象化を処理するかなり冗長なインターフェイスを記述して実装することもできます。
• 私はこれについて完全に間違っていますか？

.ashx ファイルを Web アプリケーションの開始 (または既定) ページとして設定することはできますか? もしそうなら、それはどのように行われますか？

編集- いくつかの良い提案。IIS の既定のドキュメントに "Default.ashx" を追加し、Web サイトの "既定のドキュメントを有効にする" を追加しましたが、ディレクトリの参照を無効にしているにもかかわらず、ディレクトリの一覧しか表示されません。

他の提案をいただければ幸いです。(IIS バージョン 5.1)

編集- IIS を再起動すると動作します。

質問- Visual Studio 2005 内からスタート ページを .ashx に設定することは可能ですか? これを行った後、Visual Studio 内からデバッグできないようです。

回答- アプリケーション プロパティの [Web] タブで [開始アクション] を選択できます。実際、使用するサーバー/ポートとデバッガーを選択することもできます。とてもかっこいい。

AJAX リクエストを作成し、1 つのパラメーターを渡して結果を返すような単純なタスクは、Web サービスと IHttpHandler で実行できますが、違いはどこにあるのでしょうか?

We have a custom IHttpHandler that is responsible for file downloads. The handler is mapped to URL /downloadfile.rem

The browser redirects user to URL formatted like:
/downloadfile.rem/[fileID]/[mimeType]/[fileName].[extension]
example:
/downloadfile.rem/54923876129874545456621/text$plain/data.txt

Our handler gets the supplied information from the URL and responses with file data.

This method works in IIS 6 and IIS 7, but we have a problem with the ASP.NET Development Server. It seems, that IIS 6 and IIS 7 look at the URL from left to right and stop and the "downloadfile.rem" part and correctly invoke our custom handler. The ASP.NET Development Server seems to look and the URL from right to left and decides what to do with the file based on the extension at the end of the URL. This gives a 404 reponse. When we remove the extension from the end of the URL, everything works as expected.

This is our entry in httpHandlers section:

<add verb="GET" path="downloadfile.rem" type="OurNamespace.DownloadFileHandler"/>

This is our entry in handlers section:

<add name="DownloadFile" verb="GET" path="downloadfile.rem" type="OurNamespace.DownloadFileHandler"/>

How to make it work correctly in ASP.NET Development Server?

Rationale - why we do this the way we do it?
The files for download are generated dynamically as a result of an Ajax request. Since it is an Ajax request, we cannot return the file directly to the browser, but store it on the disk for the browser to request it later. The file name on the server side is the SHA-1 of the file contents (without extension).
We could simply make the browser send a GET request to a URL like
/downloadfile.rem?fileID=37452834576542345676234?mimeType=text$plain?fileName=data.csv
and on the server side return a Content-Disposition header with "attachment; filename=...", but there is a bug in a certain version of IE 6 (that we have to support), that ignores the filename part of the header and the user will be requested to save a downloadfile.rem file.
Therefore our URL must end with the filename that should be given to the file.