У нас есть собственный 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:
Это наша запись в разделе обработчиков:
Как заставить его правильно работать в ASP.NET Development Server?
Обоснование - почему мы делаем это так, как делаем?
Файлы для загрузки генерируются динамически в результате запроса Ajax. Поскольку это Ajax-запрос, мы не можем вернуть файл напрямую браузеру, но сохраняем его на диске, чтобы браузер мог запросить его позже. Имя файла на стороне сервера - это SHA-1 содержимого файла (без расширения).
Мы могли бы просто заставить браузер отправлять GET-запрос на URL-адрес, например
/downloadfile.rem?fileID=37452834576542345676234?mimeType=text$plain?fileName=data.csv
и на стороне сервера возвращают заголовок Content-Disposition с "attachment; filename = ...", но есть ошибка в определенной версии IE 6 (которую мы должны поддерживать), которая игнорирует часть заголовка в имени файла и пользователю будет предложено сохранить файл downloadfile.rem.
Поэтому наш URL должен заканчиваться именем файла, который должен быть указан в файле.