Перезапись URL-адреса (1): IIS与ASP.NET

Чтобы полностью понять темы, обсуждаемые далее в статье, нам необходимо кратко понять процесс взаимодействия между IIS и ASP.NET. Здесь я объясняю сервер IIS 6. Что касается IIS 5 и IIS 7, то можно сказать, что первый был исключен, в то время как «классический режим» второго точно такой же, как IIS 6, а новый «конвейерный режим» фактически говорит о некоторых концепциях ASP. NET и IIS. Я считаю, что если вы понимаете IIS 6 и ASP.NET, у вас не возникнет проблем в интегрированном режиме IIS 7.

Для начала давайте взглянем на простую схематическую диаграмму, показывающую несколько основных этапов всего процесса IIS от получения запроса до возврата ответа:

1. IIS получает запрос.
2. Селектор выбирает ISAPI для обработки запроса на основе характеристик URL-адреса и конфигурации IIS — теперь естественно выбрать ASP.NET ISAPI.
3. Механизм выполнения ASP.NET получает запрос и инициализирует данные (например, создает различные объекты).
4. Начните запускать различные события Pipeline, начиная с BeginRequest.
5. После нескольких событий Pipeline ASP.NET выбирает подходящий обработчик или HandlerFactory для текущего запроса в соответствии с конфигурацией (за исключением особых обстоятельств, таких как прямой вывод результатов и завершение запроса в предыдущем событии).
6. После обработки обработчиком он проходит через несколько событий Pipeline и завершается EndRequest.
7. Выходной ответ.

Если вы хотите выполнить перезапись URL-адреса в приложении ASP.NET, вы обычно вызываете метод RewritePath HttpContext в событии BeginRequest, чтобы переместить запрос на целевой URL-адрес. Например, мы можем переопределить метод Application_BeginRequest в Global.asax, чтобы добиться этого:

причина, по которой в BeginRequest выполняется Rewrite, заключается в том, что это событие вызывается самым ранним из всех событий Pipeline. После изменения положения в это время некоторые свойства в текущем HttpContext также изменились соответствующим образом (например, HttpContext.Request.Path). Таким образом, это повлияет на логику обработчика следующих событий конвейера. Например, если разрешения необходимо определить на основе каталога, вместо запроса, полученного ASP.NET, будет использоваться «расположенный» путь. Естественно, наиболее «значительным» изменением является выбор обработчика. Например, в приведенном выше примере мы перемещаем запрос в файл «CustomerList.aspx», чтобы движок ASP.NET выбирал System.Web.UI. соответствующий *.aspx. Класс PageHandlerFactory обрабатывает запросы.

общедоступный класс Global : System.Web .
{
    protected void Application_BeginRequest (отправитель объекта , EventArgs e)
    {
        Контекст HttpContext = HttpContext .Current;
 
        если (context.Request.Path.Equals( "/Customers" ,
            StringComparison.InvariantCultureIgnoreCase ))
        {
            context.RewritePath( "~/CustomerList.aspx" );
        }
    }
}

И наконец, следует различать две концепции, а именно «конвейер ASP.NET» и «веб-формы». Обе модели являются важными в ASP.NET, но различия по-прежнему очень велики:

• Конвейер ASP.NET: каждый запрос, полученный приложением ASP.NET, будет обрабатываться через этот «конвейер». Это модель уровня ASP.NET.
• Веб-формы. Во время выполнения конвейера ASP.NET одним из шагов является выбор подходящего обработчика (или HandlerFactory) для обработки запроса. Если это aspx-страница, ASP.NET выберет класс System.Web.UI.PageHandlerFactory, в котором окончательно формируется модель WebForms.

На самом деле слово «форма» в приведенном выше предложении может быть неточным. Потому что веб-формы, вероятно, должны быть механизмом выполнения и моделью, которую можно использовать независимо, а System.Web.UI.PageHandlerFactory использует только эту модель. Когда мы пишем приложения ASP.NET, мы можем использовать эту модель в других местах в соответствии с нашими потребностями. Например, в статье « Техника: использование пользовательского контроля для генерации HTML » мы используем ascx в качестве шаблона в универсальном обработчике для генерации контента.