URL rewriting is the process of intercepting an incoming Web request and redirecting the request to a different resource. When performing URL rewriting, typically the URL being requested is checked and, based on its value, the request is redirected to a different URL. For example, in the case where a website restructuring caused all of the Web pages in the /people/ directory to be moved to a /info/employees/ directory, you would want to use URL rewriting to check if a Web request was intended for a file in the /people/ directory. If the request was for a file in the /people/ directory, you'd want to automatically redirect the request to the same file, but in the /info/employees/ directory instead.

With classic ASP, the only way to utilize URL rewriting was to write an ISAPI filter or to buy a third-party product that offered URL rewriting capabilities. With MicrosoftR ASP.NET, however, you can easily create your own URL rewriting software in a number of ways. In this article we'll examine the techniques available to ASP.NET developers for implementing URL rewriting, and then turn to some real-world uses of URL rewriting. Before we delve into the technological specifics of URL rewriting, let's first take a look at some everyday scenarios where URL rewriting can be employed.

Creating data-driven ASP.NET websites often results in a single Web page that displays a subset of the database's data based on querystring parameters. For example, in designing an e-commerce site, one of your tasks would be to allow users to browse through the products for sale. To facilitate this, you might create a page called displayCategory.aspx that would display the products for a given category. The category's products to view would be specified by a querystring parameter. That is, if the user wanted to browse the Widgets for sale, and all Widgets had a had a CategoryID of 5, the user would visit: http://yousite.com/displayCategory.aspx?CategoryID=5.

There are two downsides to creating a website with such URLs. First, from the end user's perspective, the URL http://yousite.com/displayCategory.aspx?CategoryID=5 is a mess. Usability expert Jakob Neilsen recommends that URLs be chosen so that they: · Are short. · Are easy to type. · Visualize the site structure. · "Hackable," allowing the user to navigate through the site by hacking off parts of the URL. I would add to that list that URLs should also be easy to remember. The URL http://yousite.com/displayCategory.aspx?CategoryID=5 meets none of Neilsen's criteria, nor is it easy to remember. Asking users to type in querystring values makes a URL hard to type and makes the URL "hackable" only by experienced Web developers who have an understanding of the purpose of querystring parameters and their name/value pair structure.

A better approach is to allow for a sensible, memorable URL, such as http://yoursite.com/products/Widgets. By just looking at the URL you can infer what will be displayed-information about Widgets. The URL is easy to remember and share, too. I can tell my colleague, "Check out yoursite.com/products/Widgets," and she'll likely be able to bring up the page without needing to ask me again what the URL was. The URL also appears, and should behave, "hackable." That is, if the user hacks of the end of the URL, and types in http://yoursite.com/products, they should see a listing of all products, or at least a listing of all categories of products they can view.

In addition to simplifying URLs, URL rewriting is also often used to handle website restructuring that would otherwise result in numerous broken links and outdated bookmarks.

Before we examine exactly how to implement URL rewriting, it's important that we have an understanding of how incoming requests are handled by MicrosoftR Internet Information Services (IIS). When a request arrives at an IIS Web server, IIS examines the requested file's extension to determine how handle the request. Requests can be handled natively by IIS-as are HTML pages, images, and other static content-or IIS can route the request to an ISAPI extension. (An ISAPI extension is an unmanaged, compiled class that handles an incoming Web request. Its task is to generate the content for the requested resource.)

For example, if a request comes in for a Web page named Info.asp, IIS will route the message to the asp.dll ISAPI extension. This ISAPI extension will then load the requested ASP page, execute it, and return its rendered HTML to IIS, which will then send it back to the requesting client. For ASP.NET pages, IIS routes the message to the aspnet_isapi.dll ISAPI extension. The aspnet_isapi.dll ISAPI extension then hands off processing to the managed ASP.NET worker process, which processes the request, returning the ASP.NET Web page's rendered HTML. You can customize IIS to specify what extensions are mapped to what ISAPI extensions.

In addition to mapping the incoming Web request's file extension to the appropriate ISAPI extension, IIS also performs a number of other tasks. For example, IIS attempts to authenticate the user making the request and determine if the authenticated user has authorization to access the requested file. During the lifetime of handling a request, IIS passes through several states. At each state, IIS raises an event that can be programmatically handled using ISAPI filters.

Like ISAPI extensions, ISAPI filters are blocks of unmanaged code installed on the Web server. ISAPI extensions are designed to generate the response for a request to a particular file type. ISAPI filters, on the other hand, contain code to respond to events raised by IIS. ISAPI filters can intercept and even modify the incoming and outgoing data. ISAPI filters have numerous applications, including: · Authentication and authorization. · Logging and monitoring. · HTTP compression. · URL rewriting.

Prior to ASP.NET, URL rewriting on IIS Web servers needed to be implemented using an ISAPI filter. URL rewriting is possible with ASP.NET because the ASP.NET engine is strikingly similar to IIS. The similarities arise because the ASP.NET engine: 1. Raises events as it processes a request. 2. Allows an arbitrary number of HTTP modules handle the events that are raised, akin to IIS's ISAPI filters. 3. Delegates rendering the requested resource to an HTTP handler, which is akin to IIS's ISAPI extensions. Like IIS, during the lifetime of a request the ASP.NET engine fires events signaling its change from one state of processing to another. The BeginRequest event, for example, is fired when the ASP.NET engine first responds to a request. The AuthenticateRequest event fires next, which occurs when the identity of the user has been established.

As we discussed in the previous section, ISAPI filters can be created to respond to the events raised by IIS. In a similar vein, ASP.NET provides HTTP modules that can respond to the events raised by the ASP.NET engine. An ASP.NET Web application can be configured to have multiple HTTP modules. For each request processed by the ASP.NET engine, each configured HTTP module is initialized and allowed to wire up event handlers to the events raised during the processing of the request. Realize that there are a number of built-in HTTP modules utilized on each an every request. One of the built-in HTTP modules is the FormsAuthenticationModule, which first checks to see if forms authentication is being used and, if so, whether the user is authenticated or not. If not, the user is automatically redirected to the specified logon page.

Recall that with IIS, an incoming request is eventually directed to an ISAPI extension, whose job it is to return the data for the particular request. For example, when a request for a classic ASP Web page arrives, IIS hands off the request to the asp.dll ISAPI extension, whose task it is to return the HTML markup for the requested ASP page. The ASP.NET engine utilizes a similar approach. After initializing the HTTP modules, the ASP.NET engine's next task is to determine what HTTP handler should process the request.

All requests that pass through the ASP.NET engine eventually arrive at an HTTP handler or an HTTP handler factory (an HTTP handler factory simply returns an instance of an HTTP handler that is then used to process the request). The final HTTP handler renders the requested resource, returning the response. This response is sent back to IIS, which then returns it to the user that made the request.

Creating custom HTTP modules and HTTP handlers are relatively simple tasks, which involve created a managed class that implements the correct interface. HTTP modules must implement the System.Web.IHttpModule interface, while HTTP handlers and HTTP handler factories must implement the System.Web.IHttpHandler interface and System.Web.IHttpHandlerFactory interface, respectively. The specifics of creating HTTP handlers and HTTP modules is beyond the scope of this article. For a good background, read Mansoor Ahmed Siddiqui's article, HTTP Handlers and HTTP Modules in ASP.NET.

Once a custom HTTP module or HTTP handler has been created, it must be registered with the Web application. Registering HTTP modules and HTTP handlers for an entire Web server requires only a simple addition to the machine.config file; registering an HTTP module or HTTP handler for a specific Web application involves adding a few lines of XML to the application's Web.config file.

Specifically, to add an HTTP module to a Web application, add the following lines in the Web.config's configuration/system.web section:

HTTP handlers and HTTP handler factories are configured by the tag in the Web.config's configuration/system.web section, like so:

Recall that for each incoming request, the ASP.NET engine determines what HTTP handler should be used to render the request. This decision is made based on the incoming requests verb and path. The verb specifies what type of HTTP request was made-GET or POST-whereas the path specifies the location and filename of the file requested. So, if we wanted to have an HTTP handler handle all requests-either GET or POST-for files with the .scott extension, we'd add the following to the Web.config file:

Note When registering HTTP handlers, it is important to ensure that the extensions used by the HTTP handler are mapped in IIS to the ASP.NET engine. That is, in our .scott example, if the .scott extension is not mapped in IIS to the aspnet_isapi.dll ISAPI extension, a request for the file foo.scott will result in IIS attempting to return the contents of the file foo.scott. In order for the HTTP handler to process this request, the .scott extension must be mapped to the ASP.NET engine. The ASP.NET engine, then, will route the request correctly to the appropriate HTTP handler.

URL rewriting can be implemented either with ISAPI filters at the IIS Web server level, or with either HTTP modules or HTTP handlers at the ASP.NET level. This article focuses on implementing URL rewriting with ASP.NET, so we won't be delving into the specifics of implementing URL rewriting with ISAPI filters. There are, however, numerous third-party ISAPI filters available for URL rewriting.

Implementing URL rewriting at the ASP.NET level is possible through the System.Web.HttpContext class's RewritePath() method. The HttpContext class contains HTTP-specific information about a specific HTTP request. With each request received by the ASP.NET engine, an HttpContext instance is created for that request. This class has properties like: Request and Response, which provide access to the incoming request and outgoing response; Application and Session, which provide access to application and session variables; User, which provides information about the authenticated user; and other related properties.

With the MicrosoftR .NET Framework Version 1.0, the RewritePath() method accepts a single string, the new path to use. Internally, the HttpContext class's RewritePath(string) method updates the Request object's Path and QueryString properties. In addition to RewritePath(string), the .NET Framework Version 1.1 includes another form of the RewritePath() method, one that accepts three string input parameters. This alternate overloaded form not only sets the Request object's Path and QueryString properties, but also sets internal member variables that are used to compute the Request object's values for its PhysicalPath, PathInfo, and FilePath properties.

To implement URL rewriting in ASP.NET, then, we need to create an HTTP module or HTTP handler that: 1. Checks the requested path to determine if the URL needs to be rewritten. 2. Rewrites the path, if needed, by calling the RewritePath() method.

Переписывание URL - процесс перехвата входящего веб-запроса и перенаправления запроса на другой ресурс. Когда выполняется переписывание URL, обычно запрошенный URL проверяется и, исходя из своего значения, перенаправляется на другой URL. Например, в случае, когда реструктуризация веб-сайта привела к тому, что все веб-страницы из папки /people были перемещены в папку info/employees, вы можете пожелать использовать переписывание URL для проверки, была ли запрошена страница из директории /people и (в случае успешного ответа) перенаправить пользователя на тот же файл, но из директории info/employees.

В классическом ASP была только одна возможность переписывания URL - написание ISAPI- фильтра или покупка стороннего продукта, который предлагал бы переписывание URL. В Microsoft ASP.NET вы можете легко создавать собственное программное обеспечение, выполняющее переписывание URL несколькими путями. В этой статье мы рассмотрим технологии доступные для разработчиков в ASP.NET для реализации URL-переписывания и рассмотрим конкретные примеры.

Создание ASP.NET веб-сайтов, работающих с динамическими данными, часто приводит к тому, что одна веб-страница, показывающая наборы данных из базы данных управляется строкой параметров. Например, в проектировании страницы для сайта электронной коммерции, и одной из задач является возможность пользователей осматривать продукцию. Для облегчения просмотра вы можете создать страницу displayCategory.aspx, которая позволяет просматривать заданную категорию продукции. Категория продукции указывается в строке запроса. Например, если пользователь хочеть просмотреть категории "Украшения" и эта категория имеет идентификатор 5, то пользователь обращается к странице с URL http://yoursite.com/displayCategory.aspx?categotyID=5.

Существует 2 минуса создания сайта с такими URL. Во-первых, с точки зрения пользователя такой URL - беспорядочен. Эксперт Jakob Nielsen рекомендует выбирать URL таким образом, чтобы они были: короткими, легко набираемыми, отражающими структуру сайта, "урезаемыми" (позволяющими пользователю методом обрезания частей URL попадать на новые разделы сайта). Я бы еще добавил к этому списку, что URL должна быть легко запоминаемой. URL http://yoursite.com/displayCategory.aspx?categotyID=5 не отвечает ни одному из критериев Нильсена, а также совершенно не запоминается. Заставлять пользователей вводить строку параметров в запрос делает URL сложным для набора и URL становится "урезаемым" только для опытных Web-разработчиков, которые понимают назначение строки параметров и ее парную структуру "имя"-"значение".

Лучшим подходом будет удобный и запоминающийся URL, например http://yoursite.com/products/Widgets. Просто смотря на URL, вы можете догадаться, что будет показано на странице - информация об украшениях. URL легко запомнить и поделиться с коллегой. Я скажу ему адрес, и она сможет посетить страницу без необходимости спрашивать URL заново. URL также должен быть "урезаемым". Например, пользователь обрезает URL до http://yoursite.com/products и должен увидеть список всех продуктов или, по крайней мере, перечень категорий продуктов.

В дополнение к упрощению URL, переписывание URL зачастую необходимо для реструктуризации сайта, в результате чего множество ссылок становятся "битыми" и закладки устаревшими.

Перед тем, как заняться непосредственно переписыванием URL, важно понимать, как входящие запросы обрабатываются в Microsoft IIS. Когда запрос достигает веб-сервера IIS, сервером проверяется расширение запрошенного файла с целью определения способа обработки запроса. Запросы могут быть обработаны самим сервером (такие как HTML страницы, изображения и другие статические данные) или сервер может перенаправить запрос в ISAPI-расширение ( ISAPI-расширение - неуправляемый, скомпилированный класс, который обрабатывает веб-запрос. Его задачей является генерация содержимого для запрошенного ресурса. ).

Например, если пришел запрос страницы Info.asp, сервер направит его в asp.dll ISAPI-расширение. Это расширение загрузит запрошенную страницу, выполнит ее и вернет сгенерированный HTML-код серверу, который в свою очередь пошлет его запросившему клиенту. Для ASP.NET страниц, сервер направляет сообщение в модуль aspnet_isapi.dll. Этот модуль передает обработку в управляемый рабочий процесс ASP.NET, который обрабатывает запрос, возвращая сгенерированную ASP.NET страницу. Вы можете настроить сервер таким образом, чтобы определенные расширения файлов перенаправлялись в определенные ISAPI-расширения.

В дополнение к связыванию входящего веб-запроса с подходящим ему ISAPI-расширению, сервер IIS позволяет выполнять другие задачи. Например, сервер пытается установить подлинность пользователя, который делает запрос, и определить имеет ли право этот пользователь доступ к запрошенному файлу. Во время обработки запроса, сервер проходит несколько состояний. В каждом состоянии, сервер генерирует событие, которое может быть перехвачено ISAPI-фильтром. Подобно ISAPI-расширениям, ISAPI-фильтры являются блоками неуправляемого кода установленными на веб-сервере. ISAPI-расширения предназначены для генерации ответа на запрос файла особого типа. ISAPI-фильтры, напротив, содержат код реакции на события, генерируемые сервером. ISAPI-фильтры могут перехватывать и даже изменять входящие и исходящие данные. ISAPI-фильтры являются приложениями для: 1) аутентификации и авторизации 2) Протоколирования и исследования 3) Сжатия HTTP 4) Переписывания URL

До технологии ASP.NET, переписывание URL на веб-сервере IIS было необходимо реализовывать с помощью ISAPI-фильтров. Переписывание URL доступно на ASP.NET, потому что ASP.NET машина идентична веб-серверу IIS. Подобия возникли за счет того, что машина ASP.NET: 1. Генерирует события при обработке запроса 2. Позволяет произвольному числу HTTP-модулей обрабатывать события, которые генерируются, подобно ISAPI-фильтрам 3. Поручает генерацию запрошенного ресурса HTTP-обработчику, аналогично ISAPI-расширениям Подобно IIS, на протяжении жизни запроса машина ASP.NET генерирует события, сигнализирующие о переходе из одного состояния обработки к другому. Событие BeginRequest, например, генерируется когда машина ASP.NET впервые реагирует на запрос. Событие AuthenticateRequest генерируется следующим, когда происходит установление личности пользователя.

В предыдущем разделе мы обсудили, что ISAPI-фильтры могут использоваться для реакции на события, которые генерирует сервер. В таком же стиле, ASP.NET предоставляет HTTP-модули, которые могут обрабатывать события, которые генерирует ASP.NET машина. Веб-приложение ASP.NET может быть сконфигурировано таким образом, что будет иметь несколько HTTP-модулей. Для каждого запроса обрабатываемого ASP.NET машиной, каждый сконфигурированный HTTP-модуль инициализируется и может связывать события обработчиков с событиями, генерируемыми в процессе обработки запроса. Представьте, что существует несколько встроенных HTTP-модулей, используемых в каждом запросе. Один из встроенных HTTP-модулей это FormsAuthenticationModule, который сначала проверяет используется ли метод форм для аутентификации, и если да, то аутентифицирован пользователь или нет. Если нет, то он автоматически перенаправляется на указанную страницу входа.

Вспомним, что IIS в конечном счете направляет входящий запрос в ISAPI-расширение, работой которого является вернуть данные для конкретного запроса. Например, когда поступает запрос классической ASP-страницы, IIS передает запрос в ISAPI-расширение asp.dll, чьей задачей является вернуть размеченный HTML-код для запрошенной веб-страницы. ASP.NET машина использует аналогичный подход. После инициализации HTTP-модулей, следующим заданием ASP.NET машины является определение HTTP-обработчика, который должен обработать запрос.

Все запросы проходят через ASP.NET машину и в конечном счете попадают в HTTP-обработчик или в фабрику HTTP-обработчиков (фабрика просто возвращает HTTP-обработчик, который впоследствии должен обработать запрос). Конечный HTTP-обработчик генерирует запрошенную страницу и возвращает ответ. Ответ отсылается обратно в IIS, который в свою очередь передает его пользователю.

Создание и регистрация расширенных HTTP-модулей и HTTP-обработчиков являются относительно простыми задачами, которые включают в себя создание управляемого класса, который реализует конкретный интерфейс. HTTP-модуль должен реализовывать интерфейс System.Web.IHttpModule, а HTTP-обработчики фабрики HTTP-обработчиков должны реализовывать интерфейсы System.Web.IHttpHandler и System.Web.IHttpHandlerFactory соответственно.

Как только расширенный HTTP-модуль или HTTP-обработчик создан, он должен быть зарегистрирован для веб-приложении. Регистрация HTTP-модуля или HTTP-обработчика для всего сервера требует простого добавления записи в файл machine.config; регистрация HTTP-модуля или HTTP-обработчика для отдельного веб-приложения требует простого добавления нескольких строчек XML-текста в файл web.config приложения.

По сути, чтобы добавить HTTP-модуль в веб-приложение, необходимо добавить следующие линии в файл web.config в секцию configuration/system.web: Значение type указывает сборку и имя класса HTTP-модуля, тогда как name содержит дружественное имя, по которому HTTP-модуль может быть вызван из файла Global.asax.

HTTP-обработчики и фабрики HTTP-обработчиков настраиваются с помощью тегов в секции configuration/system.web файла web.config, таким образом:

Вспомним, что для каждого входящего запроса ASP.NET машина определяет какой HTTP-обработчик должен обработать запрос. Это решение принимается на основе метода и пути запросов. Методы, с помощью которых может быть сделан запрос - GET или POST - тогда как путь указывает имя ресурса и его местоположение. То есть если мы захотим, чтобы HTTP-обработчик обрабатывал все запросы (и GET, и POST) для всех файлов с расширением .scott, не обходимо добавить следующие строки в файл web.config:

Примечание: Когда регистрируется HTTP-обработчик, важно убедиться, что расширение, используемое обработчиком, связано в IIS с машиной ASP.NET. Так, в нашем .scott примере, если расширение .scott не связано в IIS с aspnet_isapi.dll ISAP-расширением, запрос для файла foo.scott будет результатом попытки вернуть содержимое файла foo.scott. Чтобы HTTP-обработчик обработал этот запрос, расширение .scott должен быть связан с машиной ASP.NET. Тогда машина направит запрос правильно в подходящий HTTP-обработчик.

Переписывание URL может быть реализовано либо через ISAPI-фильтры на IIS веб-сервере, либо с помощью HTTP-модулей и HTTP-обработчиков на уровне ASP.NET. Поскольку эта статья посвящена переписыванию URL именно в ASP.NET, мы не будем углубляться в специфику реализации переписывания URL с помощью ISAPI-фильтров. Однако существует множество сторонних ISAPI-фильтров для переписывания URL.

Реализация переписывания URL в ASP.NET возможна через метод RewritePath() класса System.Web.HttpContext. Класс HttpContext содержит иформацию HTTP конкретного запроса. При каждом запросе, который обрабатывается ASP.NET машиной, создается новый объект HttpContext для этого запроса. Этот класс содержит свойства: Request и Response, которые предоставляют доступ ко входящему запросу и исходящему ответу; Application и Session, которые предоставляют доступ к переменным приложения и сессии; User, которое предоставляет информацию о идентифицированном пользователе.

Для реализации переписывания URL в ASP.NET, необходимо создать HTTP-модуль или HTTP-обработчик для: 1. Проверки требует ли запрошенный путь переписывания 2. Переписать путь, если необходимо, с помощью вызова метода RewritePath