11. Управление информационным наполнением

Необходимость в корректном управлении содержимым (наполнением, content) очевидна. Предположим, что создан сложный информационный сервер преуспевающей компании. На каком-то этапе был спроектирован дизайн сервера — заголовки, подвалы и элементы оформления. Однако в самом конце выяснилось, что была допущена ошибка в логотипе компании, который расположен на всех многочисленных страницах узла. Возможны также неисправности в аппаратной части компьютера. При этом может понадобиться перенаправить всех пользователей узла на другой, резервный сервер, пока производится восстановление аппаратуры.

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

Начальные действия. Сначала нужно создать веб-узел и указать, в каких каталогах хранятся публикуемые документы. Веб-сервер не может опубликовать документы, которые находятся вне пределов указанных каталогов. Первым шагом в развертывании веб-узла является задание организационной структуры файлов. После этого, используя оснастку Internet Information Services, нужно задать, какие каталоги являются частью узла.

Если необходимо опубликовать информацию немедленно, не тратя время на создание структуры каталогов узла, и все файлы расположены на одном и том же жестком диске, можно просто скопировать публикуемые файлы в основной каталог по умолчанию, \InetPub\Wwwroot. (Для FTP-узла, нужно скопировать файлы в каталог \InetPub\Ftproot.) Пользователи сети смогут обращаться к этим файлам, вводя URL-адрес http://server/имя_файла

Задание домашних каталогов. Каждый веб-узел или FTP-узел должен иметь корневой (домашний) каталог. Домашний каталог — отправная точка для организации информационной структуры публикуемых страниц. Он содержит домашнюю страницу или индексный файл, который является стартовой страницей узла и содержит ссылки на другие страницы на узле. Домашний каталог привязывается к имени домена узла или к имени сервера.

Например, если имя домена узла — www.myfirm.com и корневой каталог — \Webserver\MyFirm, то браузер, обращаясь по URL http://www.myfirm.com, получит файлы из корневого каталога. В интрасети, если имя сервера — Infoserver, то браузер, обращаясь по URL http://Infoserver, получит доступ к файлам в корневом каталоге.

Корневой каталог по умолчанию создается при установке Internet Information Services, а также при создании нового веб-узла. Корневой каталог можно изменять (рис. 22.8).

Рис 22.8. Задание домашнего каталога

Виртуальные каталоги. Чтобы публиковать информацию из любого каталога, который не содержится внутри корневого каталога, нужно создать виртуальный каталог. Виртуальный каталог— это каталог, который не содержится в корневом каталоге, но для клиента он выглядит так, как если бы он был частью корневого каталога.

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

Предположим, что для публикации информации в сети установлен узел infoserver. В табл. 22.1 показано соответствие между физическим местоположением файлов и URL, по которому файлы доступны.

Как виртуальные, так и физические каталоги (каталоги без псевдонима) видны в оснастке Internet Information Services. Виртуальный каталог обозначается в виде значка папки с глобусом в углу.

Для простого веб-узла не требуется создание виртуальных каталогов. Можно просто разместить все файлы в основном каталоге узла. Если нужно построить сложный узел или задать различные URL для различных частей узла, можно добавлять виртуальные каталоги по необходимости.

Переадресация запросов. Когда браузер запрашивает страницу с узла, веб-сервер ищет страницу по заданному URJL и возвращает ее браузеру. Когда страница перемещается внутри узла, не всегда можно исправить все связи, которые ссылаются на старый URL страницы. Чтобы удостовериться в том, что браузеры смогут найти страницу по новому URL, можно заставить веб-сервер предоставлять браузеру новый URL. Браузер использует новый URL, чтобы запросить эту страницу снова. Этот процесс называется переадресацией запроса браузера или переадресацией на другой URL. Переадресация запроса о получении страницы подобна переадресации в почтовой службе. Переадресация гарантирует, что письма и пакеты, отправленные по предыдущему адресу вашего проживания, будут доставлены по новому адресу.

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

Другие средства. Часто может потребоваться динамически изменять содержание узла после того, как содержание было затребовано, но до передачи его браузеру. IIS включает две возможности, которые обеспечивают эту функциональность — серверные включения (Server-Side Includes, SSI) и Microsoft Active Server Pages (ASP) — для создания сценариев-посредников.

Используя SSI, можно выполнять ряд действий — от динамического отображения текущего времени на странице до выполнения заданных системных команд каждый раз, когда запрашивается данный ресурс (страница). SSI-команды, называемые директивами, включаются в страницы во времени разработки. Когда страница запрашивается, веб-сервер анализирует синтаксис всех директив на странице, а затем выполняет их. Наиболее часто используется директива включения, что позволяет включать содержимое файла внутрь страницы. Например, если требуется, чтобы в заголовок страницы вставлялась реклама, можно при помощи SSI включить исходный текст рекламы. Чтобы модифицировать рекламу, нужно изменить только файл, содержащий исходный текст рекламы. Для применения SSI не нужно знать язык создания сценариев — синтаксис директив очень прост.

ASP-страницы — серверная среда создания сценариев, позволяющая динамически изменять содержимое узла. Хотя технология ASP предназначена прежде всего для разработки веб-приложений, она предоставляет много возможностей для создания более простых в управлении узлов. Например, с помощью ASP можно отслеживать посещение узла пользователями (их атрибуты— IP-адрес, тип браузера, назначенные cookies и т. п.) или настраивать содержимое узла под возможности браузера. Однако, в отличие от SSI, ASP требует применения языка создания сценария, например VBScript или JScript.

Выбор инструмента для создания страниц. Феноменальный рост сети Интернет и развитие технологий интрасетей создали огромный спрос на специализированные средства создания узлов. Если пользователь плохо знаком с основами публикации в Интернете, выбрать надлежащий инструмент для создания узла может быть достаточно сложно. Мощного сервера, предназначенного для размещения готовых страниц, недостаточно для успешного пуска и эксплуатации информационного узла в Интернете. Вот инструменты создания и публикации узлов: