Custom rewriting in ASP.NET
К сожалению, это не название какой-то технологии или библиотеки. Это всего-то значит, что url rewriting мы можем реализовать и сами.
Сразу хочу вас успокоить, есть несколько библиотек, которые реализуют эту идею, их мы рассмотрим ниже. Но, во-первых, всегда лучше
знать, по какому принципу что-то работает (помните, "знание общих принципов заменяет незнание отдельных фактов"), а во-вторых,
часто для счастья нужно совсем чуть-чуть, но вот этого чуть библиотека и не позволяет. Так что посмотрим, как можно реализовать
rewriting своими руками.
Для того, чтобы это понять, нам прийдется освежить в памяти порядок, в котором сервер обрабатывает http запросы. Честно признаться,
мне было лень рисовать подробную картинку, так что я просто позаимствовал
вот эту, а пару недостающих моментов мы дорисуем при
помощи нашей фантазии, идет?
Рис. 1
Давайте вспомним наш пример. Допустим, пользователь набирает в строке запроса браузера url http://sport.news.ru/ukraine/dinamo-kiev/:
-
Браузер обращается к DNS серверу и выясняет, что компьютер, который поддерживает доменное имя sport.news.ru имеет такой-то IP
(организация, у которой заказчик во время золотой лихорадки urls успел захватить домен news.ru, должна позаботиться,
чтобы это был IP именно нашего компьютера :).
-
Запрос попадает к IIS на нашем сервере. Тот просматривает сконфигурированные на нем сайты и ищет тот, с которым в настройках связанно
доменное имя sport.news.ru. Диалог, в котором можно задать такую связь, вызывается из оснастски IIS и выглядит так:
Рис. 2
Если соответствия не найдено, запрос передается сайту, помеченному как default.
-
А вот теперь нам пригодится немного фантазии. Посмотрите на рис.1. Блок, изображающий IIS, пустой, зато на блоке с ASP.NET
engine запрос последовательно проходит через HTTP Modules и HTTP Handlers. Теперь мысленно копируем изображение на блоке ASP.NET engine
и накладываем его на блок IIS. Дело в том, что обработка запросов как IIS, так и ASP.NET очень похожа. Сначала запрос проходит некоторое
количество фильтров (если они заданы). Пропуская запрос через себя, фильтр может каким-то образом его изменить или выполнить другую
полезную работу (логирование, аутентификация, проверка прав). Потом запрос попадает к обработчику (handler), который и должен сформировать ответ, который IIS
отошлет браузеру обратно.
Чтобы не запутаться, обратите внимание, что фильтры для IIS называются ISAPI Filters, а для ASP.NET - Http Modules.
Обработчики для IIS называются ISAPI Extensions (или ISAPI Applications), а для ASP.NET - Http Handlers.
Кроме того, до появления IIS 7.0, который входит в состав Windows Vista (уже выпущена) и в Windows Server 2008
(запуск которой назначен на 27 февраля 2008 в Лос Анджелесе), модули под IIS приходилось писать на unmanaged C++,
а вот для ASP.NET мы, естественно, можем использовать любой из .NET совместимых языков.
Итак, вернемся к нашему запросу. Вначале, он проходит через ISAPI Filters, указанные для web-сайта (кроме того, можно
задать фильтры, которые будут использоваться для всех сайтов, созданных под IIS).
Фильтры можно указывать на закладке "ISAPI Filters" диалога "Website Properties". Он приведен на рис. 3.
Рис. 3
ISAPI filters будут вызываться именно в том порядке, в котором они были указаны на закладке.
-
После этого, наступает очередь "wildcard application mappings". Эта возможность появилась в IIS 6.0. Она позволяет
указать ISAPI Applications, которые будут выполняться для любых запросов, вне зависимости от типа расширения.
Вести они себя должны как ISAPI filters (т.е. пропускать через себя запросы, возможно подправляя их или выполняя
какую-нибудь другую полезную работу. При этом, как полноценные ISAPI Applications, они обладают большими чем фильтры возможностями,
например имеют доступ не только к заголовку, но и к телу запроса.
Задать эти модули можно на закладке "Application configuration" (диалог "Website properties" ->
закладка "Home Directory" -> кнопка "Configuration" -> диалог "Application Configuration" -> секция "Wildcard application mapps").
Она приведена на рис. 4.
Рис. 4
ISAPI Applications будут вызываться в том же порядке, в котором они были указаны на закладке.
-
После этого, в зависимости от типа файла, IIS выбирает, какому из ISAPI Extensions (Applications) нужно передать управление.
Привязки типов файлов (т.е. расширений) к ISAPI Extensions можно задать на закладке "Mappings" (диалог "Website Properties" ->
закладка "Home Directory" -> кнопка "Configuration" -> диалог "Application Configuration" -> закладка "Mappings").
Эта закладка показана на рис. 5.
Рис. 5
Так, выбранная нами запись показывает, что запросы к файлам с расширением .aspx нужно передавать на обработку
ISAPI Extension aspnet_isapi.dll.