Я не хочу удалять записи из списков MIME, я просто хочу сказать IIS, чтобы они перестали обслуживать файлы с определенным расширением.
Почему так сложно заставить IIS делать что-то настолько простое, как прекращение обслуживания файла с определенным расширением?
Я видел такие решения, как ... добавить сопоставление, указывающее на какой-то 404.dll, который существует только в каком-то отдельном наборе инструментов блокировки, который в любом случае утверждает, что он устарел для IIS 6.0+. Я также читал, что ASP.NET может явно запретить обслуживание файла, создав сопоставление с dll обработчика asp.net, а затем указав System.Web.HttpForbiddenHandler в web.config для типа файла. Они работают, хотя сначала запрещенный обработчик не работал, благодаря кешу браузера, LOL: (см. Ответ на http://stackoverflow.com/questions/208571/castleproject-vm-httpforbiddenhandler-not-work) .
Я просто ищу здесь простое решение.
Я бы не позволил другим пользователям плохо объясненной проблемы отвлечь вас от использования System.Web.HttpForbiddenHandler подходить. Я подозреваю, что у него, вероятно, есть другие проблемы, которые не были адекватно объяснены в его вопросе.
Что касается картографии .fla к расширению ASP.NET ISAPI и с помощью System.Web.HttpForbiddenHandler, это работает отлично, и у нас никогда не было проблем с кешированием. Вы действительно пробовали это, вместо того, чтобы слушать слухи?
Другой подход - удалить связанный с ним mime-тип глобально или на уровне сайта.
«Почему так сложно заставить IIS делать что-то настолько простое, как прекращение обслуживания файла с определенным расширением?»
Как бы нахально не прозвучало, все вышеперечисленное не является сложным, это то, как это делается, и это не так уж много работы.
Простые решения
В IIS 7 это проще, потому что вы можете просто изменить web.config, чтобы запретить любой тип файла. В IIS 6 параметры web.config влияют только на типы файлов, которые зарегистрированы для обработки фильтром ASP.NET ISAPI.