IHttpHandler處理IIS 6，IIS 7和ASP.NET Development Server中的所有URL擴展

Question

我們有一個負責文件下載的自定義IHttpHandler。該處理程序被映射到URL /downloadfile.rem

的瀏覽器重定向到用戶URL格式，如：
/downloadfile.rem/[fileID]/[mimeType]/[fileName].[extension]
例如：
/downloadfile.rem/54923876129874545456621/text$plain/data.txt

我們的處理程序從URL獲取所提供的信息並用文件數據獲取響應。

此方法適用於IIS 6和IIS 7，但我們遇到了ASP.NET開發服務器的問題。看起來，IIS 6和IIS 7從左到右查看URL並停止和「downloadfile.rem」部分並正確調用我們的自定義處理程序。 ASP.NET開發服務器似乎從右向左查看URL，並根據URL末尾的擴展名決定如何處理文件。這給了404響應。當我們從URL末尾刪除擴展名時，一切都按預期工作。

這是我們在HttpHandlers的部分條目：

<添加動詞= 「GET」 路徑= 「downloadfile.rem」 TYPE = 「OurNamespace.DownloadFileHandler」/ >

這是我們的條目處理器部分：

<添加名稱= 「DownloadFile」 動詞= 「GET」 路徑= 「downloadfile.rem」 TYPE =「OurNamespace.DownloadFileHandle r「/ >

如何使它在ASP.NET Development Server中正常工作？

理由 - 爲什麼我們這樣做是因爲我們這樣做？
下載的文件是由Ajax請求動態生成的。由於這是一個Ajax請求，我們不能直接將文件返回給瀏覽器，而是將其存儲在磁盤上供瀏覽器稍後請求。服務器端的文件名是文件內容的SHA-1（不帶擴展名）。
我們可以簡單地讓瀏覽器發送GET請求一個URL像
/downloadfile.rem?fileID=37452834576542345676234?mimeType=text$plain?fileName=data.csv
並在服務器端返回內容處置頭文件爲「attachment; filename = ...」，但是在某些版本的IE 6（我們必須支持）中存在一個錯誤，它忽略頭文件名部分，並且將要求用戶保存下載文件.rem文件。
因此，我們的URL必須以文件名結尾。

Answer 1

嗯，我敢打賭，你永遠不會在開發服務器上部署這樣的Web應用程序，是嗎？

我不知道是否有辦法配置該服務器不驗證鏈接的存在（因爲此服務器發現您的鏈接不指向磁盤上的有效文件）。

但是，我們可以輕鬆地在IIS上做到這一點。