IHttpHandler, который обрабатывает все расширения URL в IIS 6, IIS 7 и ASP.NET Development Server

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 Development Server. Кажется, что IIS 6 и IIS 7 просматривают URL-адрес слева направо и останавливаются, а часть «downloadfile.rem» и правильно вызывают наш пользовательский обработчик. Кажется, что работает ASP.NET Development Server, и URL-адрес справа налево и решает, что делать с файлом на основе расширения в конце URL-адреса. Это дает 404 ответа. Когда мы удаляем расширение с конца URL-адреса, все работает так, как ожидалось.

Это наша запись в HttpHandlers разделе:

< добавить глагол = "GET" путь = тип "downloadfile.rem" = "OurNamespace.DownloadFileHandler"/>

Это наш запись в секции обработчиков:

< добавить имя = глагол "DownloadFile" = "GET" путь = тип "downloadfile.rem" = "OurNamespace.DownloadFileHandle г "/ >

Как сделать это правильно работать в ASP.NET сервере разработки?

Обоснование - почему мы делаем это так, как мы это делаем?
Файлы для загрузки генерируются динамически в результате запроса Ajax. Поскольку это запрос Ajax, мы не можем вернуть файл непосредственно в браузер, но сохраним его на диске, чтобы браузер запросил его позже. Имя файла на стороне сервера - SHA-1 содержимого файла (без расширения).
Мы могли бы просто сделать браузер отправить запрос GET в URL, как
/downloadfile.rem?fileID=37452834576542345676234?mimeType=text$plain?fileName=data.csv
и на стороне сервера возвращают Content-Disposition заголовок с «attachment; filename = ...», но есть ошибка в определенной версии IE 6 (которую мы должны поддерживать), которая игнорирует часть имени файла заголовка, и пользователю будет предложено сохранить файл загрузки .rem файл.
Поэтому наш URL-адрес должен заканчиваться именем файла, который должен быть указан в файле.

Answer 1

Ну, я уверен, вы никогда не развертываете такое веб-приложение на сервере разработки, не так ли?

Я не знаю, есть ли способ настроить этот сервер, чтобы не проверять наличие ссылки (поскольку этот сервер считает, что ваша ссылка не указывает на допустимый файл на диске).

Мы можем сделать это на IIS легко, однако.