Asp файл redirection

Содержание

301 перенаправление с одного сайта на другой, используя файл asp.net web.config

У меня есть страницы HTML в моем старом сайте, который нуждается в 301 редирект на страницу ASPX нового веб-сайта, как веб-сайты были построены на платформе asp.net. Пожалуйста, предложите мне, что как я могу настроить мой файл web.config для выполнения этой задачи. На данный момент я использую Meta Refresh, чтобы сделать это, но это, возможно, 200 не 301.

Любая помощь будет высоко оценена, спасибо.

Я использовал следующий кусок кода в моем старом файле web.config веб-сайт, но он не работает, а также

Создание правил в вашем файле web.config сайте

К сожалению у меня нет web.config решения для одной страницы. Вы хотите разместить это на вашей странице разметки в верхней:

Если это не работает для вас размещать разметку здесь, и я буду обновлять его для вас.

301 Redirect — Htaccess Перенаправление .asp файл

Как я 301 перенаправить в .htaccess следующую строку:

я получаю: ошибка:

Поиск в переполнении стека не помог.

Создан 07 ноя. 13 2013-11-07 20:46:28 Daan Verberne

1 ответ

Вы не можете сопоставить QUERY_STRING с помощью директивы Rediect . Используйте вместо этого mod_rewrite :

Создан 07 ноя. 13 2013-11-07 20:49:55 anubhava

У меня есть косая черта, если вы заметили. Он используется при использовании в конфигурации Apache, но не используется при использовании в .htaccess. Предоставляя ему опцию, правила работают в обоих местах. – anubhava 07 ноя. 13 2013-11-07 20:56:28

Спасибо anubhava, в конце моего URL добавлен параметр type = ind. как это исправить? – Daan Verberne 07 ноя. 13 2013-11-07 20:58:13

@anubhava Я вижу. Я думал, что это правило будет использоваться только в .htaccess. PO сказал: «Как переадресовать 301 в .htaccess» – user4035 07 ноя. 13 2013-11-07 20:59:12

@DaanVerberne: проверить отредактированный ответ. Это приведет к потере любой строки запроса в результате URI. – anubhava 07 ноя. 13 2013-11-07 21:03:05

Asp файл redirection

The redirection file is a file that you create. It usually includes script to parse the query string sent by the AdRotator object, and to redirect the user to the URL associated with the advertisement he or she clicked.

Script can also be included in the redirection file to count the number of users that have clicked on a particular advertisement, and then save this information to a file on the server.

In this section:

Copyright © 2003 Sun Microsystems, Inc. All rights reserved.

Основы архитектуры IIS, или запросопровод для ASP.NET

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

1. Общий план
2. Крупный план
2.1. HTTP.SYS
2.2. World Wide Web Publishing Service (W3SVC)
2.3. Windows Process Activation Service (WAS)
2.4. Пул приложений
2.5. Домен приложения, приложение
3. Что дальше?
Источники

1. Общий план

Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.
В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» — что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.

Рис. 1. HTTP request processing pipeline (IIS 7.x).

Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:

1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS.
2. HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации.
3. Служба WAS запрашивает конфигурацию из хранилища — из файла в папке IIS (applicationHost.config).
4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS.
6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен.
7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS.
8. HTTP.SYS отправляет ответ браузеру.

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

2. Крупный план

2.1. HTTP.SYS

На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.

Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.

Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.

Ещё HTTP.sys умеет кешировать ответы (более подробно — Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда — Use of special characters like ‘%’ ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.

Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно — Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.

Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.

2.2. World Wide Web Publishing Service (W3SVC)

Данная служба (сокращённо именуемя в спецификациях WWW service) была представлена в IIS 6 в качестве отдельного компонента для работы с протоколами HTTP/HTTPS и управления рабочими процессами приложений и выполняла следующие функции:

  • Администрирование драйвера HTTP.sys.
  • Управление рабочими процессами.
  • Мониторинг показателей производительности веб-сайтов.

Эта служба функционирует в Windows Server 2003 в контексте процесса Svchost.exe (настройки можно посмотреть в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc) в отличие от всех остальных служб IIS, которые исполняются в контексте процесса Inetinfo.exe, и реализована в Iisw3adm.dll.

В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).

Рис.2. Рабочий процесс со службами W3SVC и WAS.

Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с .NET Framework и интегрированные с IIS:

  • NetTcpActivator для протокола TCP;
  • NetPipeActivator для Named Pipes;
  • NetMsmqActivator для Message Queuing (ака MSMQ).

Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.

Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.

Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.

Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.

2.3. Windows Process Activation Service (WAS)

Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.

При активации нужного для обработки пользовательского запроса приложения задействуются следующие компоненты:

  • Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
  • Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
  • Исполняемый файл w3wp.exe – шаблон рабочего процесса.
  • Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
  • Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler — PPH) и у домена приложения (AppDomain protocol handlers — ADPH).

Ниже на рисунке представлен пример схемы компонентов внутри некоего экземпляра рабочего процесса приложения. Когда служба WAS запускает рабочий процесс, она загружает в него согласно конфигурации приложения требуемые обработчики протоколов процессов (PPH) и посредством менеджера приложений создаёт внутри рабочего процесса домен приложения, в котором будет хоститься приложение. Менеджер приложений загружает код приложения в домен приложения и требуемые обработчики протоколов уровня приложения (ADPH) для обработки сообщений по соответствующим сетевым протоколам.

Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.

Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:

А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:

В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.

Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее — маршрутизатор) – рабочий процесс.

2.4. Пул приложений

При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.

Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.

Рис. 5 Дополнительные настройки пула приложений

Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).
Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.

Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе .NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.

Рис. 6. Идеология модулей в IIS.

Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).

Встраиваемая модель предполагает более тесное взаимодействие между IIS и ASP.NET. Запрос в такой архитектуре обработки пропускается через установленную последовательность событий, в каждом из которых запрос пропускается через нативный и управляемые модули. В таком режиме модели обработки запросов IIS и ASP.NET объединены в единую модель, что позволяет избежать дублирования функций и получить больший контроль над обработкой запроса.

На практике самое важное, что необходимо учитывать при разработке и развёртывании веб-приложений, – это частичная несовместимость этих двух режимов. Т.е. при переводе сайта (точнее пула приложений, в котором работает сайт) из классической модели во встраиваемую практически всегда потребуется корректировка кода (хоть, возможно, и не значительная), а также тщательное тестирование.

2.5. Домен приложения, приложение

Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс My >
Рис. 7. Рисунок для задачки.

Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.

3. Что дальше?

Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.

Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.

Все о 301 редиректе с примерами

301 Редирект — это способ постоянного перенаправления поисковых систем и посетителей сайта на адрес, который отличается от изначально запрашиваемого. Такой ответ сервера указывает на то, что старый url утратил актуальность, страницу переместили. После переиндексации Яндекс и Google поймут куда вы теперь хотите вести посетителей и станут предлагать пользователям новый адрес.

Удивительно, но факт: с помощью редиректа можно превратить потерю в победу и привлечь на свой ресурс еще больше трафика. Но об этом чуть позже.

Если вы хотите сделать правильную настройку 301 редиректа, обязательно изучите наше пошаговое руководство с примерами кода на все случаи и различными лайфхаками.

Для чего используется 301 редирект?

Код 301 — эффективный, простой в реализации вариант переадресации web-страницы. Это удобный способ сохранения рейтинга конкретной страницы сайта.

Основные причины, чтобы добавлять 301 редирект:

  • сохранение «накопленных пользовательских сигналов» контента
  • с передачей ссылочного веса новой странице;
  • перенаправление трафика из других адресов на нужный;
  • в случае ребрендинга и смены домена, чтобы не потерять клиентов;
  • перемещение страниц;
  • склейка (с www и без, http и https);
  • удаление дублей страниц.
Илон Маск рекомендует:  plaintext в HTML

Внимание! Остановите выбор на адресе, который имеет стратегически большее значение, является предпочтительным для посетителей и поисковых систем.

Редирект можно назвать своеобразной палочкой-выручалочкой. В случае переезда всего сайта или отдельных страниц он сохранит все плоды проделанной работы: авторитет доменного имени и ранжирование в поиске. Главное — использовать перенаправление по назначению.

Сегодня вы получите 22 конкретных примера установки кода 301 и пять важных рекомендаций. С последних и начнем!

Советы по перенаправлению

Важно! Ошибки в настройках редиректов уменьшают эффект их использования.

1. Избегайте редиректов, идущих друг за другом. Каждая последующая переадресация увеличивает нагрузку на сервер, уменьшает эффективность редиректов.

Пример последовательных редиректов:

Пример последовательных редиректов

Правильным в данном примере должен быть редирект с 1 шага на 3й.

2. Размещайте правила редиректов от частных правил к общим так как противоречия частных общим могут вызывать их не срабатывание. Если частные будут ниже общих, в случае противоречий правил будут срабатывать общие как те, что идут первее по списку.

3. Из-за того что браузеры обычно запоминают перенаправления, лучше проверять код состояния HTTP через специальный сервис.

4. Переадресация не должна быть циклической, то есть странице нельзя ссылаться на саму себя.

Пример циклического редиректа: со страницы без слеша в конце URL стоит 301 редирект на страницу со слешем, на которой стоит 302 редирект обратно:

Пример циклического редиректа

5. Полезный редирект — тот, что ведет на страницу, которая во всех нюансах повторяет запрашиваемую.

Популярные виды редиректов

Желаете узнать, как сделать переадресацию? Сначала надо ознакомиться с названиями и особенностями самых используемых статусов.

Это постоянный редирект, обозначающий, что старый адрес страницы стоит считать устаревшим, контент находится на новом месте. Передает на новый документ почти весь (нет точных данных) ссылочный вес и склеивает накопленные внутренние метрики.

Представляет собой временный редирект. Не склеивает накопленные внутренние метрики страницы.

Статус ответа сервера зависит от версии протокола HTTP:

  • HTTP 1.0 — текущая публикация временно перемещена на другой url (Moved Temporarily);
  • HTTP 1.1 — документ не найден (изменения ответа на Found).

307 Moved Temporarily подходит лишь для исключительных случаев — действительно кратковременного переезда контента, например, при техническом обслуживании.

Meta Refresh

Обновления Meta являются переадресациями, которые осуществляются не на уровне сервера, а на самой странице. Чаще всего такой код ответа связан с пятисекундным обратным отчетом, дополненным текстом «Если переход не произошел за пять секунд, нажмите здесь».

Этот медленный статус относится к не рекомендованным SEO-техникам — он может привести к ухудшению поведенческих факторов и проседанию веб-страницы в органической выдаче.

Важно! В использовании постоянного редиректа нет необходимости, если ваш переезд временный или связан с проблемами старого доменного имени. При получении бана или фильтра вы перенесете прошлые проблемы на новый адрес.

В чем разница между постоянной и другими переадресациями?

302 и 301 редирект похожи между собой. Тем не менее для большинства случаев оптимальным решением станет именно постоянная переадресация.

Эти коды ответа HTTP не одинаково воспринимаются роботами и, соответственно, по-разному влияют на поисковую выдачу. Редирект 301 — знак того, что поисковику стоит забыть о старом адресе и больше никогда на него не заходить. А 302 дает сигнал о продолжении индексирования контента, размещенного на изначально запрашиваемой странице.
В случае 301 перенаправления утратившая актуальность публикация перестанет отображаться в поисковой выдаче. При 302 редиректе в индексе будут присутствовать обе страницы.

По сути, лучше всегда ставить код 301.

Временное перенаправление рекомендовано лишь в исключительных случаях, когда:

  • на запрашиваемой странице есть ссылки, которые обязаны и дальше индексироваться;
  • индексация новой страницы не является критичной.

Опыт из практики: 301 редирект против 302

Статус 302 — временная мера, сообщающая поисковикам о том, что на старой странице проходят технические работы и ее надо сохранить в выдаче.

Рассмотрим на примере. Сайт изменил доменную зону, а затем еще и обзавелся защищенным протоколом https. Однако разработчики настроили не постоянное, а временное перенаправление.

Во время работы 302 редиректа в индексе Яндекса и Google находилось 3 копии одной и той же интернет-площадки. Из-за этого произошло существенное проседание позиций.

Пример ошибки работы 302 редиректа

Когда ошибка была исправлена, роботы склеили дубли, исключив лишние страницы из своей выдачи. Сайт снова вернулся в ТОП.

301 редирект vs Canonical

Несмотря на определенные нюансы, поисковые системы установили четкие правила использования команд. Вот как их понимают Гугл и Яндекс:

  • 301 — «Моя страница навсегда переехала в другое место, она не вернется. Удалите, пожалуйста, ее из своего индекса и передайте вес новому документу».
  • Canonical — «У меня имеется несколько версий содержания страницы. Просканируйте, пожалуйста, приоритетную для меня копию, которую я пометил canonical. Остальные материалы тоже будут доступны пользователям, но индексировать их не нужно».

Когда лучше применить 301 редирект:

  • это лучший метод по умолчанию;
  • для ошибки 404 и контента, утратившего актуальность, но имеющего
  • внешние ссылки и много трафика;
  • при смене домена в результате ребрендинга или продажи ресурса;
  • для страницы, которая переехала навсегда.

Случаи использования rel=«canonical»:

  • если статья имеет нужные посетителям дубли, например, описания
  • одной и той же продукции, но разного цвета;
  • когда постоянное перенаправление реализовать трудно;
  • для кросс-доменов с похожими статьями;
  • при разных адресах одного контента (сортировка каталога).

Где настраивается 301 редирект?

В зависимости от движка, переадресацию можно выполнить разными способами.

.htaccess, или httpd.conf для Apache

Это популярный благодаря своей простоте метод, для осуществления которого надо создать файл под названием .htaccess в папке сайта. Или отредактировать, если он уже предусмотрен движком.

Важно! Перед любыми изменениями сделайте Backup редактируемого файла (или всего сайта)

Для постоянного перенаправления пропишите в начало файла, подставив свои данные:

  • Редирект всего сайта на другой адрес:

How to Redirect Folder Requests with ASP.NET

When you give a Web site URL to a potential customer, you want that URL to be as simple as possible. Normally, customers can just enter your domain name and start navigating your site from your home page.

However, sometimes you need to give customers a direct link to a specific page on your site. Giving them a full URL that includes a page name and maybe even some query string parameters is a good way to make sure they never see that page. What you really want to do is give them a simple mnemonic name that can be appended to your base URL.

Key Technologies and Concepts

Internet Information Services (IIS)

Dynamic Virtual Directories

Configuring Custom 404 Errors

Coding ASP.NET HttpModules

Redirecting Folder URLs

Data-Driven URL Redirection

Loading XML into a DataSet

For example, if you want to make it easy for customers to find your support page, you could make it so the URL http://www.MyDomain.com/Support goes directly to that page on your site. You do this easily in IIS by setting up a virtual directory called Support that is a URL redirect to your CustomerSupport.aspx page. You could also create a Support subfolder with the support page as the default document.

But what if you don’t want to go into IIS and set up a virtual directory every time you need one of these redirections, and you don’t want to litter your site with subfolders? If your site includes data-driven elements and you have an administration interface for it, wouldn’t it be better if you could just set up the redirections within that interface?

You might want to configure your redirections with a configuration file or database table for many reasons. For instance, if you want every product category in your shopping cart to have a corresponding friendly URL (e.g. www.MyStore.com/ebooks), it would be nice if you could just specify that URL when you set up the category in the shopping cart admin interface.

This article explains how to set up data-driven folder redirections so you can solve this kind of problem. My example uses an XML configuration file, but there’s no reason why you couldn’t apply the same techniques using a database.

Dealing with IIS 404 Errors

Download the Code

To download the sample code for this article, right-click over the link below and select the appropriate «Save Target As» option on the popup menu. The exact wording of this option differs a little from browser to browser.

The zip file contains a fully-functional ASP.NET 2.0 project. To set it up on your own computer, read the instructions in the Readme.pdf file.

When I initially attacked the problem of folder redirections, it seemed pretty straightforward. I figured I’d just create an HttpModule that would intercept all requests and redirect the folder requests as they came in. In fact, that worked out just fine until I moved the project from Visual Studio’s debugging environment to a virtual directory under IIS.

As soon as I moved the project to IIS, I started getting 404 errors. It turns out that IIS was intercepting my requests and determining that the folder references were invalid before it ever passed those requests on to my HttpModule. Cassini, Visual Studio’s development server, passes ALL requests down to your application, so you never see this problem.

In researching the issue, I found that there are a couple of solutions. One solution is to create a «wildcard application map» that maps all file extensions to the .NET Framework DLL. The other solution is to redirect 404 errors to your ASP.NET application.

With wildcard application maps, you bypass the normal file handling performed by IIS for you. Normally, only .NET-related file extensions would be passed to the .NET Framework for processing. Other file extensions are handled by other ISAPI filters (e.g. asp.dll, ssinc.dll, etc), or the files are simply piped down to the browser (e.g. .htm, .css, etc). Granted, ASP.NET is smart about dealing with those non-.NET extensions when it receives them, but I could not see how adding .NET to the mix would do anything good for performance.

Also, passing all files through .NET means you will apply .NET authentication to all files. For example, if you use forms authentication, the style sheet you use for your login page will be one of the things that is blocked unless you take specific steps to avoid that problem, such as turning off authentication on the folder that holds the style sheet. Having to track down and correct these side-effects was another reason why wildcarding seemed like a bad idea to me.

I obviously chose the second alternative, which is to redirect 404 errors back to my application. It is easy to set up and has no side-effects that I’ve found. Additionally, when IIS passes the 404 errors to you, it clearly identifies the URL as a 404. This feature automatically gives your HttpModule a way to filter out only the requests it needs to process.

Setting Up 404 Redirection in IIS

To set up 404 redirection in IIS, modify the site or virtual directory properties for your application as follows:

  • Open the Properties dialog for the site or virtual directory and click the Custom Errors tab.
  • Select the 404 HTTP Error and click the Edit Properties button.
  • In the Error Mapping Properties dialog (see image below), change the Message Type to URL and set the URL to your application site’s default document (e.g. «/Default.aspx») or a custom error page (e.g. «/PageNotFound.aspx»). If your application is in a virtual directory, include the virtual path (e.g. «/URLRedirect/Default.aspx»).
  • Save your changes.

Redirecting IIS 404 errors to a URL.

That’s it! Now, all 404 requests will be routed to your application for processing.

The URL that IIS hands off to you will look something like this:

The key is that «?404;» you see in the middle of the URL. The 404 parameter includes the original path that was requested by the browser. You can use it to parse out and process the original path. Your HttpModule can also use it as a quick way to identify the 404 requests it needs to process, and allow all other requests to just fall through.

Something to consider is that, after the redirect, users see the true URL of the destination page on their address bar. There are ways around that issue, but given the simple requirements of my demo application, I’m willing to live with it. Once the visitor has successfully landed on the site, the simplified URL has done its job.

Peeking at HTTP Headers

One of the tools I’ve found very useful in debugging HTTP request/response information in Internet Explorer was developed by a fellow named Jonas Blunk. His tool, named ieHttpHeaders, puts a view window at the bottom of your Internet Explorer window and shows you all of the HTTP headers that the browser sends and receives as it navigates a Web site.

The information it provides can be eye-opening. For example, when I was testing the URLRedirector demo project, ieHttpHeaders exposed the double-302 response problem I describe in the article. That first redirect is generated by IIS before you even see the request in your application, so you would only notice it if you are watching client browser activity.

You can get ieHttpHeaders from Jonas’ site:

As a side note, I’d like to point out that I recommend you put an actual page reference in the 404 custom error, rather than using an unqualified folder reference like «/» or «/URLRedirect.» If you don’t provide a page name, the visitor’s browser will receive two 302 responses for every request instead of just one. The first 302 is generated by IIS in response to the unqualified redirect to your application, and the second redirect is generated by your module. (See the side bar «Peeking at HTTP Headers» for information about how you can detect that first redirect.) If you provide a page name, it appears that IIS can transfer the initial request directly to the page you specify, so the browser only sees the 302 generated by your module.

Hooking into the HTTP Pipeline

One of the most powerful aspects of ASP.NET is the way Microsoft provided easy-to-use hooks into the processing cycle of HTTP requests and responses, which is referred to as the HTTP Pipeline. In the old days, hooking into the pipeline meant writing an ISAPI filter, which was not an exercise for the timid.

One of the pipeline hook points gives you full access to the HTTP request before it hits your Web page, which lets you inspect, change, or redirect the incoming request. This is the hook you’ll use to perform URL redirection.

To tap into the pipeline, you create an HttpModule. An HttpModule is essentially a filter that you can apply at the Web application level. In fact, the module has application scope and lifetime, which can come in handy as I explain shortly. Your module gets first shot at incoming requests (and last shot at outgoing responses), so it is an excellent location to handle URL rewriting of any kind.

Attaching an HttpModule to your application is surprisingly easy. All you have to do is write the module class and add a configuration setting to your Web.config. You can create a separate assembly for the module, but you don’t have to. You can just place the module class in the App_Code folder of your project and test it from there. For simplicity, that is the approach I chose in the demo project.

The Web.config settings go in configuration/system.web/httpModules. The setting in the demo project looks like this:

Writing an HttpModule

The code inside the HttpModule is also surprisingly simple. You write a class that implements the IHttpModule interface. The interface includes only two methods: Init and Dispose. Here’s the entire source code for the module from the demo project. I explain each section in detail below:

The Init method bootstraps your module and gives you a way to hook a method call from your module into the HTTP pipeline. ASP.NET calls the Init method of all modules specified in Web.config when your Web application initializes.

When ASP.NET calls the Init method, it passes a reference to the current HttpApplication object. Using this reference, you can hook your own handlers onto any HttpApplication event. In my case, I want to hook into the BeginRequest event, which is accomplished with the following line of code:

You can call the event handler anything you want. I just followed the VB.NET convention of Class_EventName. The signature of the event handler must match the signature of the BeginRequest event, of course.

If you need to do anything else to initialize your HttpModule, put it in the Init method after your AddHandler statement. In my case, I need to grab the desired redirections from a configuration file and load them into a DataSet for easy processing. I cover that operation in more detail shortly.

In the Dispose method, you can put any shutdown code related to the actions you performed in the Init method. For demonstration purposes, I set the DataSet I loaded to Nothing, even though the reference would be dropped automatically when the module instance is dropped.

Coding a BeginRequest Handler

The next step is to add code to your BeginRequest event handler. The BeginRequest event happens before the request is passed to the appropriate page handler, so you get to mess with the request before the page even sees it. It is a perfect opportunity to tweak the headers or content in the request, or even redirect it.

ASP.NET passes a reference to the current HttpApplication object as the first parameter, and event arguments (which I won’t need for this exercise) in the second. Since I do need to use the application reference, I cast the reference to an appropriately defined variable right up front.

The application reference gives me access to the current HttpRequest object, which in turn gives me access to the requested URL.

Now, what I do with that URL depends upon whether I’m running under IIS or Visual Studio. The «Option 1» code passes all requests through the redirection filter (RedirectKnownPath) because I don’t get a 404 error redirect from the Visual Studio Web server.

The «Option 2» code, which you should use when running under IIS, passes only 404 errors through the redirection filter. Of course, for that code to work properly, you have to redirect 404 errors back to the application, as I described earlier.

The Option 1 code also works just fine under IIS, but it is wasteful. Unless you use the 404 filtering logic or some kind of file extension filtering, every document request that ASP.NET processes loops uselessly through the redirection filter.

How you handle true 404 errors is up to you. By «true 404,» I mean that IIS could not find the requested path, and the RedirectKnownPath method did not redirect the path either. In the demo project, I redirect all true 404 errors to the home page. I describe a couple of other alternatives later in the article.

Configuring Paths for Redirection

Before I dig into the guts of the redirection logic, it is important to understand how I configured the redirection paths. I had several choices. I could have gotten them from a database, from a Web service, or from some kind of configuration file.

To keep the demo project simple, I used an XML configuration file (Redirection.xml) to define what paths to look for and where to send the browser if a configured path is found. I refer to these configured paths as «known paths.»

The configuration file looks like this:

You can put as many Redirection elements as you need within the Redirections document node. Redirection elements have a RequestPath attribute that defines what path to look for and a Target attribute that defines where to redirect the response when the RequestPath is found. The redirection module compares the value in RequestPath to the end of the original request using the EndsWith string method. The attribute value is not case sensitive.

You could obviously get a lot fancier here. For example, you could use regular expressions in the RequestPath with corresponding code in your HttpModule to process them. Again, given my simple requirements, matching the end of the URL works out just fine.

The cool thing about using an XML file is that you can easily load it into a DataSet and process it just as if the data did come from a database. That is what the additional code in the module’s Init method does.

Keep in mind that an HttpModule has application lifetime. When I load the configuration file into a module instance variable, that means I am effectively caching the data for the lifetime of the application. If I make a change to my configuration file, those changes won’t do anything until I restart the application. If you need a more dynamic solution than that, use a different approach, such as the ASP.NET Cache (with a timeout) or a file watcher.

Redirecting Known Paths

The RedirectKnownPaths method is responsible for performing the following tasks:

  • Parse the originally requested path out of the URL.
  • Compare the trailing characters of the original path to the configured paths.
  • If a match is found, redirect the browser to the destination URL associated with the configured path.

The first thing the code does is look in the URL for a 404 parameter. If it finds the 404 parameter, it parses the 404 URL to extract the path originally requested by the browser.

Being able to do «404 filtering» is one of the advantages of using the IIS 404 redirect approach: you automatically get a way to filter out just the requests that might require redirection. This capability is helpful from an efficiency standpoint because your module has to process every single request that gets serviced by ASP.NET, even the ones in which you have no interest. In contrast, using wildcard mapping not only eliminates the ability to do 404 filtering, but it causes all document requests (not just ASP.NET document types) to go through your module.

The rest of the method loops through the rows in the cached DataSet of redirections, seeking a match on RequestPath. If the original URL ends with the value configured in RequestPath, the method redirects the browser to the corresponding value in Target.

If you don’t find a matching «known path,» the request just continues through its normal path through the ASP.NET pipeline.

Resolving True 404 Errors

I’ve shown you how to deal with 404 errors that are known paths and need to be redirected. But what if you get a 404 error that is not a known path? In other words, it is a genuine 404 error.

If you don’t actively redirect unknown path requests to a specific page, the request falls through to ASP.NET. Where it goes from there depends upon what path you put into the custom 404 error in IIS.

If you use Default.aspx (or the name of any existing page in your project) in the redirect path of your custom error, you have an interesting situation. ASP.NET displays the Default.aspx page, but the browser address line will show the path that generated the 404 error. Hmm. It seems that all unknown paths lead home!

On the other hand, you can create a custom 404 error page and use that page as the custom 404 error path in IIS. Once again, the browser will show the bad path in the address line, but your error page will let visitors know that the path is invalid.

I tend to think that using a custom 404 page is the most user-friendly solution. The visitor knows what happened, and you can also give them links to the home page and your contact page. The demo project includes PageNotFound.aspx, which does just that. If you go back to the IIS properties dialog image, you’ll see that I used PageNotFound.aspx in my error redirect.

Илон Маск рекомендует:  Запрет повторения фона

However, the demo project forcefully redirects all true 404 errors to Default.aspx, so you never actually see PageNotFound.aspx. That’s easy to correct: just comment-out the redirect to Default.aspx. The 404 error will fall through to PageNotFound.aspx instead, and the browser address bar will show the URL that failed.

Conclusion

I hope this article gave you some ideas on how to build your own folder redirection module. As simple as the demo project is, it demonstrates several useful skills:

  • Creating an HttpModule and hooking it into the HTTP Pipeline.
  • Loading XML files into a DataSet.
  • Configuring custom 404 errors in IIS.
  • Processing IIS 404 errors.

If you expand the demo project with a few extra features like getting redirections from a database, caching redirections with a timeout, and using regular expressions to match requested paths, you could put the module into its own assembly and have a robust tool that you could use in all of your ASP.NET projects.

Of course, you can also do an Internet search and find third-party URL redirection and rewriting tools. Some are even free. But if your needs are simple, building your own redirection tool gives you valuable experience and full control over how the tool works.

Please see the Download the Code side bar for instructions if you’d like to download the demo project presented in this article.

How to redirect a Url in IIS6/IIS7 and in ASP.NET?

First of all, as David pointed out, there are two (or three in David’s terms) types of redirects:

· Client-side redirection : the server sends a “302 Redirect” response to the client together with the new location header.

· Server-side redirection : the server rewrites the request with another URL transparently and the client is not aware of anything.

Client-side redirection

It is also called HTTP redirection. You can achieve it in the following ways.

Redirect in IIS6

You can use the HttpRedirect Metabase setting to perform redirection in IIS6. This property can be set to a virtual application, a file, or a virtual directory (a.k.a. web folder). It requires the physical existence of these “source” items. To achieve that, you can use IIS Manager. Here are the steps on how to set it for a file:

· Right click on the file and click on Properties

· Click on “File” tab of the dialog

· Select “A redirection to a URL” radio box

· Type in your new Url, and/or make any other changes, and click OK.

After this, you would have setup the file so that all requests to this file is redirected to the new Url. You can check the Metabase setting with the following command:

cscript.exe %SystemDrive%\Inetpub\AdminScripts\adsutil.vbs get /w3svc/1/Root/foo/p1.aspx/HttpRedirect

If the file does not have any Metabase property pre-defined in the Metabase, you cannot use adsutil.vbs to set this property. But you can set it with the script to a virtual application.

Redirect in IIS7

In IIS7, the concept is similar as that of IIS6. You can use the new command “appcmd.exe” to enable redirection as following:

%windir%\system32\inetsrv\appcmd set config «Default Web Site/foo» -section:system.webServer/httpRedirect -enabled:true -destination:»http://localhost/bar/p1.aspx»

This tells IIS to redirect all request sending to the virtual application “/foo” to “/bar/p1.aspx”. The actual result is that appcmd.exe adds the following section to the web.config file for the application “/foo”:

httpRedirect enabled = » true » destination = » http://localhost/bar/bbb.aspx » />

Redirect with ASP.NET

You can also use ASP.NET to implement client-side redirection. If you don’t want ASP.NET pipeline to intercept any such request, you would need to implement the logic in the global.asax file. This is important for WCF applications since WCF intercepts requests from the pipeline for WCF requests. Here is some sample code for a global.asax file:

This approach is more flexible than those provided by IIS:

· It does not require the existence of the physical file.

· It is imperative and thus you can add any custom programming logic to determine whether you want to redirect the request. For example, you can check the query string to see whether it contains the information that requires a redirection.

Server-side redirection

It is sometimes also called Url rewriting or Url aliasing. One of the advantages for server-side redirection is performance because there is no round-trip involved if the redirection is on the same machine.

Virtual Directories: HTTP Redirection

Downloads
26256.zip

In «Virtual Directories: Targeting Local Directories and Network Shares,» September 2002, InstantDoc ID 25930, I explain how you can use IIS’s virtual-directory structure to selectively publish the content of physical directories without exposing their locations. In that article, I discuss the two most popular content sources: a local directory (i.e., a directory on the Web server) or a network share. A third option exists: redirection from one URL to another. Redirection can help you manage ever-changing content locations and directory structures. To prevent your clients’ browsers from running into the infamous URL Not Found error, get to know the basics of HTTP redirection, as well as the range of available options that let you take advantage of IIS’s capabilities.

The Basics of Redirection
IIS uses HTTP redirection features to notify clients of new locations for existing URLs. (The lengthy Internet Engineering Task Force—IETF—Request for Comments—RFC—2616 fully describes HTTP.) The structure is fairly simple: A Web client such as Microsoft Internet Explorer (IE) sends a request, and the Web server responds to that request. In its common form, such a request looks like the following:

The METHOD attribute (aka the verb) is an action that the client wants the server to perform. GET and POST are the most common methods. GET requests usually don’t carry data to the server, although they can send a short amount (i.e., about 1KB) of text-based data in a query string. (A query string is the text string that follows the question mark in a URL. For example, the URL http://alto http://www.windowswebsolutions.com, InstantDoc ID 26302.)

The URL attribute is the HTTP request, which is a path (or an HTML document) relative to the Web server’s home directory. For example, the URL for a request to http://altoid/scripts/myscript.asp would be /scripts/myscript.asp.

HTTP_Version is a string identifying the HTTP protocol version that the client is using. The server can reply by using the specified version or an earlier version. (The most recent available version is HTTP 1.1, but a server can reply with HTTP 1.0.) This attribute prevents the server from replying with a version that the browser can’t handle.

HeaderName identifies the headers that the HTTP protocol uses to transfer auxiliary information (i.e., Header_Value in the sample request) from the client to the server and vice versa. Some headers are required for each HTTP request (e.g., the Host header for HTTP/1.1 requests, the Location header for 302 Redirect server replies), but many headers are optional. For example, browsers usually identify themselves with the optional User-Agent header. Each header in a request ends with a carriage return and line feed; the final header in a request terminates with a double carriage return and line feed.

The BODY attribute is mandatory for all POST method requests in which the Content-Length header isn’t zero. The BODY can be any type of data. For an HTTP form request, the BODY might be a buffer of name=value pairs (e.g., Fname=Leon). When a client encounters the input type=file HTML tag (which is used to upload files to a server), the BODY might be a large binary buffer.

The following output shows a sample GET request. This request for a default document is from a browser using HTTP 1.1.

After receiving a request, the Web server responds to the client. In its simplest form, a standard response looks like the following:

STATUS_CODE is a numeric value that defines the status of the completed operation. The standard success reply is 200 OK, as in the following:

The status code is the most important part of HTTP redirection. IIS natively supports two redirection status codes: 302 Redirect and 301 Move Permanently. You can redirect any virtual directory, physical directory, Web site (by redirecting the root directory), or file to a new target location. When you configure an IIS server to perform redirection, the server sends the 302 Redirect status code (unless you specify permanent redirection) and the Location header, which can represent an absolute URL (e.g., http://server/page.htm) or a relative URL (e.g., /newdir/page.htm). To show that a URL has moved permanently, the server can reply with the 301 Move Permanently status code. These status codes instruct the browser to send a new request to the URL that the Location header specifies. A simple redirection looks like the following:

Keep in mind that when you configure redirection, you increase the number of requests necessary to get to the specified URL. Browsers will always need to send at least two requests: one to the original URL and one to the new URL.

Know Your Options
Configuring redirection for a virtual directory involves a few steps in the Microsoft Management Console (MMC) Internet Information Services snap-in. First, create a local directory on the IIS server, then open the directory’s Properties dialog box and go to the Virtual Directory tab. Select the A redirection to a URL option, and specify the redirection target in the Redirect to text box. The example that Web Figure 1 (http://www.windowswebsolutions.com, InstantDoc ID 26256) shows configures redirection for the sample Scripts virtual directory and specifies the relative URL /newscripts; the absolute URL http://altoid/newscripts would also work. Relative URLs work only for redirection that takes place on the same physical machine. When you want to redirect requests from one machine to another or redirect requests to a Secure Sockets Layer (SSL)­enabled site (even one on the same machine), you must use an absolute URL. After I set up the sample redirection that Web Figure 1 shows, the IIS server will redirect requests to http://altoid/scripts/myscript.asp to http://altoid/newscripts/myscript.asp. When a browser receives a 302 Redirect response, the browser sends a new request to the server. Therefore, the final URL’s appearance in the browser contains no trace of the original URL. The only proof that redirection took place is in the W3SVC log file, which reveals the originally requested URL, as Web Figure 2 shows.

Notice that in the example that Web Figure 1 shows, I didn’t select the The exact URL entered above check box. If I had selected this check box, IIS would always redirect any request directly to http://altoid/newscripts. This action would cause an error if the URL http://altoid/newscripts didn’t permit a directory listing or define a default document. The exact URL option works best when you’re redirecting specific files, not directories.

When you want to redirect the entire home directory (i.e., the Default Web Site) to a subdirectory below it, select the A directory below this one check box. Be aware that in my tests, this option doesn’t work for nested subdirectories, for example to redirect http://server/dir1 to http://server/dir1/subdir1. To redirect the home directory, open the Internet Information Services snap-in. Open the Default Web Site object’s Properties dialog box, go to the Home Directory tab, select the A redirection to a URL and A directory below this one check boxes, and enter the relative path of any directory under \inetpub\wwwroot.

To force permanent redirection (i.e., to generate 301 Move Permanently replies instead of 302 Redirect replies), select the A permanent redirection for this resource check box. Be aware, however, that this option doesn’t change browser behavior. (Ideally, browsers would not only retrieve new URLs but also update any bookmarks the browsers used to get to the original URL. However, I’ve yet to see a browser that could perform this task.)

Add Power with Variables and Wildcards
Along with these simple redirection options, you can use several variables and wildcards in the specified redirection target—in conjunction with the The exact URL entered above option—to create a complex, dynamic redirection according to rules you put in place. Each variable represents a part of the original URL, as follows:

    $S represents the original URL’s suffix. For example, in a request for http://alto >Let’s look at an example of how you can use these variables. Suppose you’ve changed your virtual-directory structure, moving content from the Scripts directory to the Newscripts directory, and asked all users to update their bookmarks. You can configure a tricky redirection to determine how many users are still requesting the original directory and thus to determine when you can safely delete that directory. You can even go one step further and write a script that shows users a friendly reminder to update their bookmarks.

First, configure redirection for the http://altoid/scripts virtual directory. Select the A redirection to a URL and the The exact URL entered above options, then enter the following target:

This target uses the $S and $Q variables to preserve the original parameters of all requests to http://alto >

Next, you can write a simple Active Server Pages (ASP) script that determines the presence of the Redir parameter, as Listing 1 shows. Now, attempts to access the original URL will redirect users to the page that Web Figure 3 shows. You can add code to the script to count how many times the script was invoked with the Redir=1 parameter. This count will show how many users are still using the old URL.

IIS redirection also supports wildcards. An asterisk (*) denotes any number of characters in the original URL, with the variables $0 to $9 representing the matched part of the expression. The target URL must start with an asterisk; followed by a portion of the original URL, using the wildcard character; then the matching destination URL, using the $0 to $9 variables. Use semicolons to separate these three sets of characters. For example, suppose you’ve just installed ASP.NET and want to redirect all requests for .asp files in the Scripts directory to .aspx files in the same directory, preserving all other parameters. As Figure 1, page 4, shows, set up redirection to a URL, select the The exact URL entered above option, and enter the following target:

Upon receiving a request for http://alto >

One final variable exists. The $! variable stops the redirection. Consider the following redirection target:

This target routes all requests for .htm files to default.htm. Therefore, any direct access to default.htm produces an infinite loop of redirections. To prevent this loop, specify a redirection target of $! for the default.htm file.

Add Scripts for Interactivity
Although variables and wildcards offer expanded options, they don’t permit true interactivity—for example, redirecting a request according to the client’s browser version. To accomplish this type of redirection, however, you need to write an ASP script that performs programmatic redirection through the Response.Redirect ASP method. Such scripts can be simple yet still create a complex redirection according to any business rule you choose.

The script that Listing 2 shows retrieves a User-Agent string (which identifies browser version) from the client, then searches that string for the presence of the MSIE substring (which identifies the browser as IE). If the script locates the MSIE substring, the script displays a welcome message. Otherwise, the script automatically redirects the browser to the IE home page. You can incorporate the code that Listing 2 shows into an ASP application designed to work only with IE. You don’t need to configure IIS redirection for this script to work.

You can use the script that Listing 3 shows to set up an interactive Web page that performs redirection according to user selection. Place this .asp file in the virtual directory that permits reading and execution of scripts. When users navigate to the file, they’ll see a list of the specified news sites, an option to select a site, and a Go! button. Selecting the desired site and clicking Go! will automatically redirect the browser to the selected site.

Final Thoughts
A few known problems with IIS redirection exist. One is a failure to redirect correctly when the browser sends a URL that terminates in a forward slash (/), for example http://server/myvdir/. The Microsoft article «HTTP Redirect URL Corruption When Requested URL Contains a Trailing Forward Slash» (http://support.microsoft.com/default.aspx?sc (http://support.microsoft.com/default.aspx?sc >

With only a few caveats, IIS offers excellent HTTP redirection facility. Whatever your skill level, you can use IIS’s redirection options—from typing a simple URL to writing a complex ASP script—to direct users to the proper resources.

Oops
«IPSec Packet Filtering» (September 2002) includes an incorrect InstantDoc ID. The correct InstantDoc ID for that article is 25935. We apologize for any inconvenience this error might have caused.

Web Development — Redirecting Old Asp Files To New Aspx Files (Permanent Redirect, SEO)

I upgraded my site from asp to asp.net.This means that all of my previous asp files became obsolete.I don’t want to lose my Google Ranking of the old pages.

What is the proper way to redirect?I tried to catch all of the old asp pages is my 404 and then to:

if Request.QueryString(«aspxerrorpath»).contains(«index.asp») = true then
Response.Status = «301 Moved Permanently»
Response.AddHeader(«Location», «http://www.domain.com/index.aspx»)
Response.Redirect(«/index.aspx»)
end if

but it doesn’t catch asp pages, only aspx.

Similar Messages:

Permanent Redirect Legacy Routes For Static Files In MVC?

Our old ASP.net site stored static images in a sub directory on the root called /images.

Our new ASP.net MVC site stores these images in the new layout of /Content/Images

I’ve changed all the pages in the site to cope with the new folder structure, but I’d like to set up Permanent Redirects from the old static images to the new location.

Make Visual Studio Treat .htm Files Like .aspx Files?

I’ve inherited a bunch of code that has server script inside of .htm files.

On IIS, a handler mapping pumps.Htm pages though the asp.net engine.

Unfortunately, visual studio doesn’t notice that they should be treated as code.

Is there any way to make VS treat .Htm files as code/aspx files?

Auto Generating Code-behind Files From .aspx Files?

I have a designer working on several pages in Dreamweaver. The designer is creating .aspx files with the Page directive at the top. These are getting shipped to me and I’m adding them to the Visual Studio ASP.NET WebForms Web Application Project. The problem is that there’s no code-behind file by default, and I’m trying to find a shortcut to have them autogenerated as if I’ve added a fresh page from Visual Studio.

How To Redirect Aspx Files That Are «Not Found»

I recently migrated my site from a aspx site to wordpress. The wp site is now hosted on rackspace cloud.

When I go to index.aspx I get the following message:

Server Error in ‘/’ Application.
The resource cannot be found.
Description: HTTP 404. etc.

Previous times I have done a migration like this I uploaded a file index.aspx with a redirection inside and that worked well, but now it doesn’t seem to find the file at all.

Nor did a redirect from the htaccess, nor the redirection plugin. I just get that same message.

Open Aspx Files Directly By Clicking On Them Like Html Files Without From Within Visual Studio Or Visual Web Dev?

is it possible to open aspx files directly by clicking on them like html files without from within visual studio or visual web dev?

Web Forms :: Make Sub Domains Or Redirecting Files For Users

On a membership website that every user has an acount how to give a user place or page in the way below: assume that website is [URL] then we have a user with acount Jimmy now I want to have a link like : [URL] that gives general information about jimmy to other users. one solution is to make a sub directory on root named jimmy and have an index.aspx file in that. it is space consuming and I do not want to do it. Is there any other briliant solution for this problem that for example I can use just one page and take jimmy as query string or something like that to show jimmy’s information?

Http — Make 301 Permanent Redirect?

how to make 301 permanent redirect in asp.net?

I have written code in Global.asax file but my web client says it is not working,

i have written follwing code in Global.asax file:

protected void Application_BeginRequest(object sender, EventArgs e)
<
if (HttpContext.Current.Request.Url.ToString().ToLower().Contains(
«http://lsatfreedom.com»))
<
HttpContext.Current.Response.Status =
«301 Moved Permanently»;
HttpContext.Current.Response.AddHeader(«Location»,
Request.Url.ToString().ToLower().Replace(
«http://lsatfreedom.com»,
«http://www.lsatfreedom.com»));
>
>

C# — Detecting If Referrer Was From A 301 Permanent Redirect?

I am doing a 301 permanent redirect from an old server to a new server. When the new server’s page is hit I want to be able to determine whether the user comes from the old site and then react differently, i.e. instruct user to re-book mark the new page.

Crystal Reports :: VS 2010 On Development Machine Can’t Find Folder Containing The Required Files?

When I attempt to test my new report on my workstation in Visual Studio 2010 running the beta Crystal Reports for 2010 it can not find the folder containing the required files.

Is there a way to force it to find them so I can debug the code calling the report?

Make Permanent 301 Redirect Work When There Are Parameters In The Query String?

I moved some of my old asp pages to new aspx website. In all of the old pages i used (for file example.asp):

Response.Status = «301 Moved Permanently»;
Response.AddHeader(«Location»,»http://www.domain.com/example.aspx»);

The problem is that when the page domain.com/example.asp?param=value&param2=value2 is requested — the redirect ain’t working.

Configuration :: Deployment Of Web Application With Aspx.cs Or Aspx Files Only?

If we are deploying ASP.NET web application, Do we need to copy both *.aspx and *.aspx.cs files on the server?Also what if I am using different framework version? I mean 1.1 / 2.0 /3.0 /3.5 /4.0? What will be the answer in different .NET Framework versions?

Change Encoding Of All Aspx And Aspx.vb Files In A Project?

I need to change the encoding from Western European. to Unicode. for every file in the project. I do not want to have to check out, open, change encoding, save and check-in every file, is there a faster way?

VS2008 + TFS 2008

C# — IIS Redirect Moved Files?

I would like to reorganize the directory structure on a hosted website (i.e. I can not go in and configure the IIS settings).

Say I had 3 files in the root directory:

fruitcake.html,
chocolateCake.html, and
appleMuffins.html

Now, I want to move them to a new folder called Recipes. This is easy enough, but there are a lot of existing links out there that point to the other files. How would I construct a 404.aspx page to read in which file was in the address bar, then update the browser to go to the new location?

Web Forms :: How To Load Files (file1.aspx And File1.aspx.vb) In A Container On Index.aspx

I want to know how can I load my files (file1.aspx and file1.aspx.vb) in a container on my index.aspx. My index should have my menu and my container. My problem is that i don’t know how do that. options wich i tried:

Iframes: yes work it. but in html 5 iframe will dissapear.

MasterPage: isn’t the solution because this refresh all index page.

Ajax: yes.. charge my File1.aspx in the container but i can’t call the functions of File1.aspx.vb.

Setup Some Permanent Redirects For .asp To Aspx Pages?

Our old site is in Classic ASP, and we know there are many people who have pages bookmarked. The new pages will be written in .Net.I thought of url rewriting (overkill?), but I’m not sure how to set that up (if this is the best way, I’ll need some links to tutorials for using it in this specific manner. I’ve seen it used by never done it myself)What is the best, most efficient way setup some permanent redirects for these .asp to aspx pages?

Илон Маск рекомендует:  Римская нумерация

Aspx.vb And .aspx.cs Files In Application?

In my project I have both the vb(.aspx.vb) and c#(.aspx.cs) files. Can i run both the files in my single application? or how to run?

Can Server .html Files Using Razor As If They Were .cshtml Files Without Changing The Extension Of All My Pages

I manage a large asp.net site which has previously been converted from static html site to asp.net. For several reasons (mainly SEO) we decided not to rename all the files to .aspx back when we originally converted the site. This was very easy to do by simply adding the buildProvider and httpHandler to the web.config.

Now I am upgrading the site to use Asp.net WebPages with Razor cshtml files. I can rename all the files if necessary, and use url rewriting to make the urls stay the same, however it would be much easier if I could just configure the web.config to tell it to parse .html files as if they were .cshtml. I have searched around quite a bit, and could not find anything equivalent to the PageHandlerFactory for razor pages. It appears as though it is just an internal mechanism in the .net 4.0 ISAPI handler.

The site is currently running on Windows 2003 server and IIS 6. We will be upgrading to 2008/IIS 7.5 in the near future, but I’d prefer not to wait for that. Is there any way to get the .html files to be parsed by razor as if they were .cshtml files?

I basically want to do a reverse ‘search in all files’, so it returns files that don’t contain «keyword».Does anyone know how to do this, or the regex used, etc?

Configuration :: ResourceManager And Resx Files — Files To Display Items In Multiple Languages

I have an application that uses resource files to display items in multiple languages. My app uses quote a lot of javascript and the alerts need to display in the local language. To do this, I have created an http handler which will read the keys and values of the culture-specific resource file and write them to a JSON array which is then embedded in the page in a script tag, the messages can then be accesses using, for exmaple:

Message.Error (en-GB = «Error», fr-FR = «Erreur»)

The messages http handler works great in development, however when I run the application on a test server, I get the error: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure «Resources.Alerts.resources» was correctly embedded or linked into assembly «App_GlobalResources.b0n9j90e» at compile time, or that all the satellite assemblies required are loadable and fully signed. The code that I use to acccess the resource file is:

ResourceManager manager = Resources.Alerts.ResourceManager;
ResourceSet resourceSet= Resources.Alerts.ResourceManager.GetResourceSet(Thread.CurrentThread.CurrentCulture, true, true);

Where Resources.Alerts is the type that contains my multi-lingual definitions. The build action for the Alerts.resx file is set to «Embedded Resource». Any ideas why this works locally but not on my test server, am I missing something?

Security :: Non-asp Files / Moved The Pages And Files To Other Folders And Set The Web.config File On This Folder?

I was following the tutorials from this two sites:

Following the first site, it had worked but when I�ve moved the pages and files to other folders and set the web.config file on this folder, now it won�t work at all.

The file is an *.swf object. I did put the asapi.dll to map the extension on the website root, I�ve put the

on the web.config new folder and on the web.config website�s root.

It won�t work. I can access the file directly. on the web.config of the folder that contains the file, there is a line.

Installation :: After Installing Server 2008 The Program Files Disapper With The SQL .MDF Files?

I am not sure this is the forums but I dont know where to write this and this is an EMERGENCY ::I had windows 2003 server. on C: and I have installed windows 2008 server.I had SQL server installed and all of the database files stored inside c:program filessql server. PROBLEM is that after I installed 2008 server I can see 2 folders of program files one for x86 and the other for 64 bits.

Send Form Files To The Server Just To Get Summary Filesize Without Sending The Whole Files?

I have a form with 10 file inputs. They can contain 10 random files with random sizes. If I send these files to ASP.NET server with this code:

var count = HttpContext.Current.Request.Files.Count;
var TotalSize = 0;
for (int i = 0; i

Deploy Files Is Connecting With Remote Desktop Client And Send Files

i have a production server that does not have ftp access. Possible way to deploy files is connecting with remote desktop client and send files.

As you know this approach is highly hard and time inefficient.

SQL Server :: How To Open Different Types Of Files / Display All The List Of Files In Gridview

I am trying to open different types of files that I have uploaded on my sql server database. I would like to display all the list of files in Gridview. When user click the link it should open download dialog box and should be able to open its particular applications such as word, excel, browsers etc.

Как работают Web сервисы ASP.NET

Введение

Сегодня существует два фундаментально различных способа реализации Web сервисов, основанных на HTTP, в Microsoft® .NET. Первой и наиболее низкоуровневой техникой является написание специального класса IHttpHandler, который вставляется в цепочку .NET HTTP pipeline. Этот подход требует использования System.Web API для обработки входящих HTTP сообщений и System.Xml API для обработки конверта SOAP, находящегося в теле HTTP. При написании специального обработчика также требуется создать вручную документ WSDL, который точно описывает вашу реализацию. Чтобы сделать все это правильно, необходимо глубокое понимание спецификаций XML, XSD, SOAP и WSDL, что является для большинства устрашающим условием.

Более продуктивным способом реализовать Web сервисы является использование WebMethods оболочки Microsoft ASP.NET. С ASP.NET поставляется специальный класс IHttpHandler для .asmx (называемых WebServiceHandler), который обеспечивает набор необходимых вам функциональных возможностей XML, XSD, SOAP и WSDL. И, поскольку WebMethods оболочка защищает вас от сложностей, лежащих в основе XML технологий, вы можете быстро сосредоточиться на существующих проблемах бизнес логики.

Рисунок 1. Соотношение выгод и потерь между гибкостью и продуктивностью

Выбор между техниками реализации приводит к общему сравнению выгод и потерь между гибкостью и продуктивностью, как показано на Рисунке 1. Создание специального IHttpHandler дает вам неограниченную гибкость, но также требует большего времени на написание, тестирование и отладку кода. Оболочка WebMethods облегчает организацию вашего Web сервиса и быстроту разработки, но вы явно ограничены рамками оболочки. Однако в случаях, когда оболочка WebMethods не обеспечивает именно того, что вам надо, есть возможность расширить ее, добавляя собственные дополнительные функциональные возможности.

В общем, пока вы не освоили XML, XSD, SOAP и WSDL и не хотите утруждаться, работая с ними напрямую, лучше продолжайте работать с оболочкой WebMethods. Она поставляет основные сервисы, которые необходимы большинству конечных Web сервисов, а также некоторые интересные возможности расширения, которые позволяют привести оболочку в соответствие вашим конкретным надобностям. Исходя из этого, далее в статье обсуждаются внутренние механизмы работы WebMethods. Если вы новичок в XML Schema и SOAP, перед тем как продолжить прочитайте Understanding XML Schema ( http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnxml/html/understandxsd.asp ) и Understanding SOAP ( http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnsoap/html/understandsoap.asp ).
Оболочка WebMethods

Оболочка WebMethods занимается преобразованиями SOAP сообщений в методы класса .NET. Это делается, прежде всего, путем аннотирования ваших методов атрибутом [WebMethod], находящемся в пространстве имен System.Web.Services. Например, следующий класс .NET содержит четыре метода, два из которых аннотированы атрибутом [WebMethod]:

Чтобы использовать этот класс с оболочкой WebMethods, вам надо компилировать его в сборку и скопировать в виртуальную директорию директории bin. В этом примере методы Add и Subtract затем могут быть раскрыты как операции Web сервиса, в то время как с методами Multiply и Divide этого сделать нельзя (т.к. они не были отмечены атрибутом [WebMethod]).

Вы раскрываете Add и Subtract как операции Web сервиса через .asmx файл. Чтобы сделать это, создайте новый текстовый файл Math.asmx, содержащий следующее простое описание, и поместите его в ту же виртуальную директорию, которая содержит и сборку (обратите внимание: файл помещается в саму виртуальную директорию, а не в ее дочернюю директорию bin):

Это описание указывает обработчику .asmx, какой класс использовать для WebMethods, а обработчик чудесным образом заботится обо всем остальном. Например, предположим, виртуальная директория называется ‘math’ и содержит Math.asmx наряду с тем, что дочерняя директория bin содержит сборку, вызов http://localhost/math/math.asmx приводит к тому, что обработчик .asmx генерирует страницу документации, показанную на Рисунке 2 (см. далее).

Это один из основных вариантов работы обработчика .asmx. Файл .asmx обычно содержит только описание WebService, которое ссылается на класс Web сервиса по имени (как в примере, показанном ниже). Следовательно, в этом случае, сборка должна уже быть скомпилирована и размещена в директории bin виртуальной директории. Обработчик .asmx также обеспечивает JIT компиляцию исходного кода, находящегося в файле .asmx. Например, следующий файл (названный Mathjit.asmx) содержит описание WebService вместе с исходным кодом класса, на который ссылается.

Когда к этому файлу доступаются через HTTP впервые, обработчик .asmx компилирует источник и правильно размещает сборку. Обратите внимание, что в описании WebService должен быть также указан и язык программирования, чтобы обработчик .asmx мог выбрать в среде выполнения правильный компилятор. Явным недостатком этого подхода является то, что вы не знаете об ошибках компиляции до тех пор, пока не обратитесь к файлу.

Рисунок 2. Документация MathService

При создании нового проекта Web сервиса в Visual Studio® .NET вы всегда используете технику “двух файлов”, когда исходный файл класса отделен от файла .asmx, который на него ссылается. Интегрированная среда разработки (IDE) хорошо скрывает это от вас, но если вы нажмете Show All Files на панели инструментов Solution Explorer, вы увидите в проекте по два файла для каждого класса Web сервиса. Кстати, Visual Studio .NET не поддерживает для файлов .asmx синтаксическое выделение или IntelliSense®, поэтому вы сами решаете, следовать ли в этом направлении. В Web проектах Visual Studio .NET также заботится о создании виртуальной директории и автоматическом компилировании сборки в директорию bin виртуальной директории.

Перед погружением в детали работы обработчика .asmx давайте коротко обсудим, как обрабатываются сообщения от Internet Information Server (IIS), прежде всего, в обработчике .asmx. Когда входящее HTTP сообщение достигает порта 80, для того, чтобы определить, какая ISAPI DLL должна использоваться для его обработки, IIS использует информацию метабазы IIS. Инсталляция .NET связывает расширения .asmx с Aspnet_isapi.dll, как показано на Рисунке 3.

Рисунок 3. Связываение IIS и .asmx

Aspnet_isapi.dll – это стандартное расширение ISAPI, поставляемое .NET Framework, которое просто направляет HTTP запросы в отдельный рабочий процесс, называемый Aspnet_wp.exe. Aspnet_wp.exe выполняет роль хоста для общеязыковой среды выполнения и .NET HTTP pipeline. Как только сообщение входит в .NET HTTP pipeline, pipeline просматривает в файле конфигурации, какой класс IHttpHandler надо использовать для данного расширения. Если вы посмотрите свой файл Machine.config, то увидите, что он содержит httpHandler, связанный с расширением .asmx, как показано здесь:

Итак, когда сообщение поступает в .NET HTTP pipeline, нацеливаясь на файл .asmx, pipeline заходит в класс WebServiceHandlerFactory, чтобы создать новый объект WebServiceHandler, который может использоваться для обработки запроса (с помощью метода IHttpHandlerProcessRequest). Затем объект WebServiceHandler открывает физический файл .asmx, чтобы определить имя класса, содержащего ваш WebMethods. Более подробная информация о работе .NET HTTP pipeline представлена в HTTP Pipelines: Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/02/09/HTTPPipelines/default.aspx).

Сразу после того, как .NET HTTP pipeline вызывает обработчик .asmx, чудесным образом начинается обработка XML, XSD, SOAP и WSDL. Остальные функциональные возможности, предоставляемые обработчиком .asmx, могут быть разделены на три основные группы: 1) координирование сообщений, 2) преобразование XML в объекты и 3) автоматическое генерирование WSDL и документации. Давайте каждую из этих групп рассмотрим более детально.
Диспечеризация сообщений

Когда HTTP pipeline вызывает обработчик .asmx, просматривая описание WebService в файле .asmx, он определяет, какой класс .NET использовать. Затем он просматривает поступившее HTTP сообщение, чтобы определить, какой именно метод вызывать в данном классе. Чтобы вызвать операцию Add, показанную в предыдущих примерах, входящее HTTP сообщение должно выглядеть примерно так:

На самом деле во входящем HTTP сообщении есть два участка, которые могут использоваться для определения метода, который должен быть вызван в классе: заголовок SOAPAction или имя запрашиваемого элемента (т.е. имя элемента в пределах элемента soap:Body). В этом случае хотя бы один из них определяет имя метода, который хочет вызвать отправитель.

Для диспечеризации сообщения обработчик .asmx по умолчанию использует заголовок SOAPAction. Значит, обработчик .asmx смотрит на заголовок SOAPAction в сообщении, а затем, используя .NET рефлексию, проверяет методы класса. Он рассматривает только методы, помеченные атрибутом [WebMethod], но, просматривая значение SOAPAction каждого метода, он точно определяет, какой метод вызывать. Поскольку мы явно не определили значение SOAPAction в методах нашего класса, обработчик .asmx принимает, что значением SOAPAction будет сочетание пространства имен Web сервиса и имени метода. Поскольку мы также не определили и пространство имен, обработчик по умолчанию присваивает http://tempuri.org. Таким образом, значение по умолчанию SOAPAction для метода Add будет http://tempuri.org/Add.

Вы можете изменить пространство имен Web сервиса, помечая класс атрибутом [WebService], так же как и точное значение SOAPAction, помечая WebMethods атрибутом [SoapDocumentMethod], как показано далее:

Теперь обработчик .asmx ожидает, что значение SOAPAction для метода Add будет http://example.org/math/Add и urn:math:subtract для метода Subtract (поскольку мы явно задали это значение). Например, следующее сообщение HTTP запроса вызывает операцию Subtract:

Если обработчик .asmx не находит SOAPAction, подходящего для входящего HTTP сообщения, он просто формирует исключительную ситуацию (позже рассмотрим, как обрабатываются исключительные ситуации). Если для диспечерезации метода вы не используете заголовок SOAPAction, помечая класс свойством RoutingStyle атрибута [SoapDocumentService], вы можете указать обработчику .asmx использовать имя элемента запроса. Если вы делаете это, то также надо указать, что WebMethods не нуждаются в значении SOAPAction, путем установления их значений в пустую строку, как показано ниже:

В этом случае обработчик даже не рассматривает значение SOAPAction – он использует вместо него имя элемента запроса. Например, ожидается ,что имя элемента запроса для метода Add будет Add (из пространства имен http://example.org/math), как показано в этом сообщении HTTP запроса:

Значит, первое, что делает обработчик .asmx при получении входящего HTTP сообщения, – он определяет, как перенаправить сообщение в соответствующий WebMethod. Однако до того как он действительно сможет вызвать метод, он должен преобразовать входящий XML в .NET объекты.
Преобразование XML в объекты

Как только обработчик WebMehod определил, какой метод надо вызвать, он должен десериализовать XML сообщение в .NET объекты, которые могут быть предоставлены во время вызова метода. Так же как и при диспечеризации сообщения, обработчик проверяет класс с помощью рефлексии, чтобы выяснить, как обрабатывать входящее XML сообщение. Класс XmlSerializer осуществляет автоматическое преобразование между XML и объектами в пространстве имен System.Xml.Serialization.

XmlSerializer делает возможным преобразование любого public типа .NET в тип XML Schema и, вместе с тем, может проводить автоматические преобразования между .NET объектами и документами XML (см. Рисунок 4). XmlSerializer ограничен теми возможностями, которые сегодня поддерживает XML Schema, поэтому он не может работать со всеми сложностями сегодняшних объектных моделей, такими как комплексные не древовидные диаграммы объектов, дублирующие указатели и т.д. Несмотря на это, XmlSerializer может работать с большинством комплексных типов, используемых разработчиками.

Для приведенного выше примера Add XmlSerializer преобразует элементы x и y в .NET double значение, которые затем смогут предоставляться при вызове Add. Метод Add возвращает вызывающему значение типа double, которое затем должно быть опять сериализовано в XML элемент в рамках SOAP ответа.

Рисунок 4. Преобразование XML в объекты

Также XmlSerializer может автоматически работать с комплексными типами (за исключением описанных выше ограничений). Например, следующий WebMethod вычисляет расстояние между двумя структурами Point:

SOAP сообщение запроса для этой операции будет содержать элемент Distance, который включает два дочерних элемента, orig и dest, и каждый из этих элементов должен содержать дочерние x и y элементы:

В этом случае SOAP сообщение ответа будет содержать элемент DistanceResponse, включающий элемент DistanceResult типа double:

Применяемое по умолчанию XML преобразование использует имя метода в качестве имени элемента запроса и имена параметров в качестве имен дочерних элементов. Структура каждого параметра зависит от структуры типа. Имена public полей и свойств просто преобразовываются в дочерние элементы, как в случае x и y (в Point). Именем элемента ответа по умолчанию становится имя элемента запроса, оканчивающееся словом «Response». Элемент ответа также содержит дочерние элементы, названные так же как и элементы запроса, только оканчивающиеся словом «Result».

Есть возможность освободиться от стандартного XML преобразования путем использования большого количества встроенных атрибутов преобразования. Например, для преобразования имени типа и пространства имен можно использовать атрибут [XmlType]. Чтобы контролировать то, как параметры или члены класса преобразовывают элементы или атрибуты, вы можете пользоваться атрибутами [XmlElement] и [XmlAttribute], соответственно. А для контроля за тем, как сам метод преобразовывается в имена элементов в сообщениях запроса/ответа, можно воспользоваться атрибутом [SoapDocumentMethod]. Например, ознакомьтесь со следующей версией Distance, в которой используются различные атрибуты:

В этой версии Distance ожидается, что входящее SOAP сообщение будет выглядеть следующим образом:

И будет сгенерировано такое SOAP сообщение ответа:

Для реализации и определения приведенного выше преобразования, применяемого по умолчанию, обработчик .asmx использует документ/литерал стиль SOAP. Это означает, что описание WSDL будет содержать буквенные определения XML schema, описывающие и элементы запроса, и элементы ответа, используемые в SOAP сообщениях (т.е. правила SOAP кодирования не используются).

Обработчик .asmx также делает возможным использование rpc/литерал стиля SOAP. Это означает, что SOAP Body содержит XML представление вызова RPC и параметры сериализовываются с использованием правил SOAP кодирования (т.е. XML Schema не нужна). Соответственно, вместо атрибутов [SoapDocumentService] и [SoapDocumentMethod] вы используете [SoapRpcService] и [SoapRpcMethod]. Более подробно о различиях в этих стилях см. в разделе MSDN Understanding SOAP (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnsoap/html/understandsoap.asp).

Как видите, есть возможность полностью изменить процесс преобразования данного метода в SOAP сообщение. XmlSerializer обеспечивает мощный механизм сериализации со многими возможностями, о которых у нас нет времени здесь говорить. Более подробно о том, как работает XmlSerializer, см. в разделе MSDN Moving to .NET and Web Services (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/11/webserv/). Я также рассмотрел многие нюансы XmlSerializer, не раскрытые в моей ежемесячной колонке MSDN Magazine, XML Files (http://msdn.microsoft.com/msdnmag/find/default.aspx?type=Ti&phrase=XML%20Files) (смотрите список колонок в online архивах).

Кроме работы по десериализации параметров, обработчик .asmx также может десериализовать/сериализовать SOAP заголовки. SOAP заголовки обрабатываются не так, как параметры, поскольку они обычно считаются несвязанной информацией без прямой привязки к конкретному методу. Поэтому обработка заголовка обычно делается с помощью уровней перехвата, полностью защищающих WebMethods от необходимости иметь дело с обработкой заголовков.

Если, все-таки, вы хотите использовать информацию заголовка из WebMethod, вы должны предоставить класс .NET, наследуемый от SoapHeader, который представляет XML Schema заголовков (следуя рекомендациям преобразования, приведенным выше). Затем вы определяете переменную члена этого типа, выполняющую роль «заполнителя» для экземпляров заголовка. И наконец, вы помечаете каждый WebMethod, нуждающийся в доступе к заголовку, определяя имя того поля, куда вы хотите его направить.

Например, SOAP запрос, содержащий заголовок UsernameToken с целью аутентификации:

Чтобы сделать возможной для обработчика .asmx десериализацию заголовка, сначала надо определить класс .NET, представляющий предполагаемый тип XML Schema (обратите внимание: если у вас на самом деле есть XML Schema для заголовка, вы можете генерировать класс, используя xsd.exe /c). В этом случае соответствующий класс выглядит следующим образом:

Затем просто надо определить переменную члена в вашем классе WebMethod, чтобы хранить экземпляр класса заголовка , и аннотировать WebMethods атрибутом [SoapHeader], как показано ниже:

Затем в WebMethod вы можете обратиться к полю Token и извлечь информацию, которая была предоставлена заголовком. Вы также можете отправить заголовки обратно клиенту, используя ту же технику – вам просто надо определить направление заголовка в описании атрибута [SoapHeader]. Более подробную информацию об обработке SOAP заголовков в оболочке WebMethods см. в разделе MSDN Digging into SOAP Headers with the .NET Framework. (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnservice/html/service06182002.asp)

Обработчик .asmx также обеспечивает автоматическую сериализацию исключительных ситуаций .NET. Любая необработанная исключительная ситуация,перехваченная обработчиком .asmx, автоматически сериализуется в элемент SOAP Fault в ответе. Например, в предыдущем примере, если имя пользователя не совпадает с паролем, наш код формирует исключительную ситуацию .NET. Тогда обработчик .asmx обработает ее и сериализует в SOAP ответ, как показано ниже:

Если вы хотите еще больше контролировать элемент SOAP Fault, вы можете также явно сформировать объект SoapException, определяя все детали элемента SOAP Fault, такие как элементы faultcode, faulstring, faultactor и detail. Более подробная информации представлена в разделе MSDN Using SOAP Faults (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnservice/html/service09172002.asp).

Как видите, чтобы понять, как работает WebMethods, необходимо еще разобраться с механизмом, лежащим в основе сериализации, и всем многообразием его возможностей. Преимуществом механизма сериализации является то, что он скрывает весь лежащий в основе XML API код, который обычно вам приходится писать в специальном обработчике. Однако, в то время как большинство разработчиков считают это положительным моментом, некоторые называют это недостатком, потому что все еще хотят самостоятельно работать с SOAP сообщением в пределах реализации WebMethod. Более детально о том, как использовать такой смешанный подход, см. в разделе MSDN Accessing Raw SOAP Messages in ASP.NET Web Services (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/03/03/WebServices/default.aspx).
Автоматическое генерирование WSDL

Клиентам надо точно знать, как должно выглядеть SOAP сообщение, чтобы успешно работать с ним. Общепринятым является предоставлять описания Web сервиса через WSDL (и встроенные XSD определения). Для этого обработчик .asmx автоматически генерирует и страницу документации, и описание WSDL, которое точно отражает интерфейс WebMethod. Если вы применили группу атрибутов преобразования к вашим WebMethods, все они будут отражены в сгенерированной документации.

Если вы посмотрите файл .asmx, то найдете страницу документации, такую как показано на Рисунке 2. Эта страница документации генерируется страницей .aspx, называемой DefaultWsdlHelpGenerator.aspx (находящейся в C:windowsMicrosoft.NETFramework v1.0.3705config). Если откроете файл, вы увидите, что это всего лишь стандартная страница ASP.NET, которая использует .NET рефлексию для генерирования документации. Эта возможность позволяет документации всегда соответствовать коду. Просто модифицируя этот файл, вы можете изменять генерируемую документацию.

Также можно блокировать генерирование документации на основе виртуальной директории, определяя другой файл документации в файле Web.config:

Если клиент завершает запрос GET для .asmx символами «?wsdl» в строке запроса, обработчик .asmx вместо документации генерирует описание WSDL. Клиенты могут использовать описание WSDL для генерирования proxy классов, которые автоматически знают, как общаться с Web сервисом (т.е. используя Wsdl.exe в .NET).

Чтобы изменить процесс генерирования WSDL, вы можете написать класс SoapExtensionReflector и зарегистрировать его с оболочкой WebMethods в файле Web.config. Затем, когда обработчик .asmx будет генерировать описание WSDL, он вызовет ваш класс и даст вам возможность изменить окончательное описание, поставляемое клиенту. Более подробно о том, как писать классы SoapExtensionReflector, см. в разделе MSDN SoapExtensionReflectors in ASP.NET Web Services (http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030320WebServicesMP/manifest.xml).

Используя две различные техники, вы можете полностью блокировать процесс генерирования WSDL. Во-первых, для доступа клиентами вы можете предоставить статический WSDL документ в вашей виртуальной директории и затем блокировать генератор документации, удалив его из вашего файла Web.config, как показано ниже:

Немного более автоматизированной техникой является использование атрибута [WebServicesBinding] для определения местоположения статического документа WSDL в виртуальной директории, которую реализовывает класс WebMethod. Вы также должны определить имя WSDL binding, которое реализовывает каждый WebMethod, используя атрибут [SoapDocumentMethod]. Процесс автоматического генерирования WSDL импортирует ваш статический WSDL файл и «завернет» его в новое описание сервиса. Более подробная информация по этой технике представлена в статье MSDN Place XML Message Design Ahead of Schema Planning to Improve Web Service Interoperability (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/02/12/WebServicesDesign/).

Сегодня очень тяжело вручную создавать WSDL, потому что до сих пор нет достаточного количества доступных редакторов WSDL. Поэтому автоматическое генерирование документации/ WSDL является ценной частью оболочки WebMethods, которая облегчит жизнь многим разработчикам.
Заключение

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL