Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

100

Часть

П.

Компоненты программного обеспечения

Web

http://images.bar.coin/foo3.gif, которое размещено на images.bar.com. Изображе-

ния могут размещаться и поддерживаться другой компанией, www.images.com, для

чего используется встроенная ссылка http://www.images.com/ fooimages/fooS.gif.

Размещение изображений на отдельном сервере дает возможность основному

Web-серверу обрабатывать большой поток запросов на небольшие и часто меняю-

щиеся HTML-документы.

Web-сервер функционирует на компьютере, имеющем доступ к сети. Компью-

тер имеет один или несколько процессоров, память и жесткие диски для хранения

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

тельной мощности, способам подключения к сети и объему накопителей, выбор

платформы определяется типом Web-ресурсов и ожидаемой интенсивностью кли-

ентских запросов. Web-сервер взаимодействует с процессором, дисковой памятью

и сетевым соединением через посредство операционной системы. Для Web-сайтов,

обслуживающих большое число пользователей, Web-сервер устанавливается на от-

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

множество других приложений, например, сервер электронной почты или FTP-cep-

вер,

либо пользовательские приложения. Для выполнения пользовательских запро-

сов сервер может исполнять сценарии, которые взаимодействует с другими серве-

рами или системами управления базами данных. При взаимодействии с другими

серверами может использоваться как HTTP, так и другие протоколы.

4.2.

Выполнение клиентского запроса

Web-серверы предоставляют доступ к разнообразным ресурсам: от статических

файлов до сценариев, которые динамически генерируют ответы. В этом разделе мы

рассмотрим этапы выполнения клиентского запроса. Далее мы обсудим, как

Web-серверы осуществляют аутентификацию пользователей с целью ограничения

доступа к определенным ресурсам. Затем будет описано, как Web-серверы динами-

чески генерируют содержимое путем синтаксического анализа HTML-файлов и

вызова сценариев. Наконец, мы поговорим о роли cookies в сохранении состояния

между последовательно выполняемыми одним и тем же пользователем запросами.

4.2.1.

Этапы выполнения клиентского запроса

На верхнем уровне Web-сервер выполняет следующие действия по обработке

HTTP-запроса:

Чтение и синтаксический анализ сообщения HTTP-запроса. Сервер читает

сообщение запроса, отправленное клиентом. Заголовок сообщения содержит

управляющую информацию, например, запрашиваемую операцию (например,

GET) и URL запрашиваемого ресурса (например, /foo.html). Сервер может

извлекать другие поля заголовков, которые влияют на построение сообще-

ния-ответа.

Преобразование URL в имя файла. Сервер преобразует URL в имя файла

соответствующего ресурса. URL может иметь прямое отношение к структуре

базовой файловой системы. Например, Web-ресурсы могут располагаться

в каталоге, например, /www, тогда URL http://www.bar.com/foo/index.html

будет соответствовать файлу /www/foo/index.html.

Разрешение на выполнение запроса. Прежде чем сформировать сообще-

ние-ответ, сервер проверяет, имеет ли клиент разрешение на доступ к ресур-

Глава

Web-серверы

101.

су. Хотя многие Web-ресурсы доступны для любых пользователей, сервер мо-

жет ограничить доступ к некоторым ресурсам на основе информации о пра-

вах доступа в заголовке HTTP-запроса.

Формирование и передача ответа. Сервер генерирует сообщение-ответ, ко-

торое содержит заголовок с информацией о состоянии (например, наличие

ошибки, связанной с несанкционирова1Н1ым доступом или обращением к не-

существующему ресурсу, переадресация клиента к ресурсу с другим URL, ус-

пешный ответ, содержащий запрашиваемый ресурс). Кроме того, заголовок

может содержать метаданные о ресурсе, такие как его длина и формат.

В определенный момент в ходе обработки запроса сервер может записать ин-

формацию о запросе и ответе в свой журнал. Например, сервер может сформиро-

вать запись в журнале перед или после передачи сообщения-ответа.

В качестве примера обработки запроса обратимся к классическому примеру,

представленному ранее во второй главе (раздел 2.3.1). Клиент отправляет НТТР-за-

нрос на ресурс http://www.bar.com/foo.html серверу www.bar.com. Сервер читает

сообщение для определения имени /foo.html запрашиваемого ресурса. Затем сервер

идентифицирует соответствующий файл /www/foo.html и определяет, что для дос-

тупа к этому ресурсу авторизация не требуется. Далее сервер инициирует системные

вызовы для получения атрибутов ресурса, таких как размер файла и дата последней

модификации. Эти атрибуты фигурируют в заголовке HTTP-ответа (поля заголовка

Content-Length и Last-Modified) вместе с другой информацией, такой как информа-

ция о состоянии ответа, идентификационные данные сервера и текущее время. По-

сле создания заголовка ответа сервер передает заголовок и содержимое файла обра-

тившемуся с запросом клиенту.

После получения сообщения-ответа клиент осуществляет синтаксический ана-

лиз HTML-файла и выдает HTTP-запросы для каждого из встроенных изображе-

ний

fool.gif,

foo2gif и fooS.ipg. Сервер обрабатывает эти запросы точно таким же

образом, как и запрос на foo.html. При ответе на каждый запрос сервер извлекает

соответствующий файл, формирует заголовок ответа, после чего передает заголо-

вок и данные. Содержимое любого из этих файлов может изменяться, не оказывая

влияния на работу сервера. Кроме того, сервер не устанавливает каких-либо взаи-

моотношений между ресурсами на Web-странице. Такие взаимоотношения уста-

навливаются автором документа foo.html путем указания ссылок на каждое из изо-

бражений в HTML-файле. Браузер инициирует извлечение этих изображений пу-

тем отправки HTTP-запросов серверу, а сервер независимо обрабатывает каждый

из этих запросов.

Сообщение-ответ сервера не всегда содержит ресурс. В качестве примера пред-

положим, что в браузере имеется кэшированная копия документа foo.html. Не

зная, был ли ресурс изменен сервером, браузер может отправить запрос на под-

тверждение актуальности кэшироварнюй копии. Браузер включает время послед-

ней модификации кэшировапиого ресурса в заголовок запроса. После получения

такого запроса сервер определяет время последней модификации файла /www/

foo.html. Если оба времени совпадают, значит, что ресурс не был изменен с момен-

та последнего его запроса браузером. Сервер отправляет сообщение-ответ с заго-

ловком, который указывает, что запрашиваемый ресурс не был модифицирован,

инструктируя браузер использовать кэшированную копию. В этом случае сообще-

ние-ответ не включает в себя содержимое ресурса. С другой стороны, если файл

/www/foo.html был изменен, сообщение-ответ сервера будет включать содержимое

файла.

102

Часть

Компоненты программного обеспечения

Web

4.2.2.

Управление доступом

Web-сервер может ограничивать доступ пользователей к определенным ресур-

сам. Управление доступом требует сочетания аутентификации (проверка подлин-

ности) и авторизации (проверки

полномочий).

При аутентификации определяется

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

может ли пользователь иметь доступ к определенному ресурсу. Сначала мы рас-

смотрим, как Web-сервер осуществляет аутентификацию пользователя с помощью

агента пользователя. Затем мы обсудим, как Web-сервер определяет, может ли

пользователь иметь доступ к запрашиваемому ресурсу.

АУТЕНТИФИКАЦИЯ

Большинство систем клиент-сервер аутентифицируют пользователя, запраши-

вая у него имя и пароль. В этой модели па сервере имеется файл, содержащий име-

на и пароли всех зарегистрированных пользователей; с целью защиты информации

пароли могут храниться в зашифровагнюм виде. Пользователь вводит имя и па-

роль в начале сеанса работы с сервером. Сервер проверяет это имя и пароль и со-

храняет информацию о пользователе на данный сеанс. В определенный момент

пользователь или сервер завершает сеанс. Для дальнейшего доступа пользователю

необходимо инициировать новый сеанс работы с сервером, что подразумевает по-

вторный ввод имени

1^1ароля.

В Web отсутствует понятие сеанса работы пользователя с сервером. У пользова-

теля создается впечатление сеанса работы с Web-сайтом, состоящего из последова-

тельности запросов к Web-страницам. Сервер же, со своей стороны, видит лишь

поток независимых HTTP-запросов. В известном смысле каждый запрос принадле-

жит своему собственному сеансу. Следовательно, Web-сервер должен выполнять

аутентификацию для

каждого

запроса па ресурс, для которого предусмотрены ог-

раничения доступа. Однако пользователь может посчитать обременительным вво-

дить имя и пароль при каждом HTTP-запросе, включая запросы на встроенные

изображе1П1я. Вместо этого сервер предписывает агенту пользователя включать ин-

формацию об имени и пароле в заголовок HTTP-запроса. Пользователь вводит

имя и пароль, которые сохраняются до тех пор, пока пользователь не закроет брау-

зер.

Запоминание агентом пользователя имени и пароля дает возможность серверу

выполнять аутентификацию, по-прежнему трактуя каждый запрос независимо.

Любые промежуточные компоненты между агентом пользователя и исходным сер-

вером просто пересылают информацию о пользователе.

Предположим, что пользователь щелкает мышью на гиперссылке, которая соот-

ветствует защищенному ресурсу на сервере www.bar.com. Браузер отправляет на

Web-сервер НТТР-занрос. Сервер распознает, что запрашиваемый ресурс имеет ог-

раничение на доступ. Сервер возвращает HTTP-ответ, который указывает, что за-

прос требует аутентификации. Ответ также указывает, какой вид аутентификации

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

обычную (basic) или с помощью дайджеста (digest) [FHBH^99]. Ответ также ука-

зывает на

область

(realm)

—

строку, которая объединяет множество ресурсов сер-

вера. Каждое множество может иметь свою схему аутентификации с различными

именами и паролями. Далее браузер запрашивает у пользователя имя, пароль и

включает эту информацию в последующие запросы. Подробнее о НТТР-аутепти-

фикации будет рассказано в главе 7 (раздел 7.10).

Глава 4. Web-серверы 103

ПРОВЕРКА ПОЛНОМОЧИЙ

Процесс аутентификации дает возможность серверу идентифицировать пользо-

вателя, обратившегося с HTTP-запросом. Для управления доступом к Web-ресур-

сам сервер должен реализовать стратегию проверки полномочий (авторизации).

Серверу нужен эффективный способ определения, какие аутентифицированные

пользователи могут иметь доступ к определенному ресурсу. Подобные стратегии

поведения являются составной частью настройки сервера. Такая стратегия поведе-

ния обычно находит выражение в виде списков управления доступом, которые со-

держат пользователей, которым разрешен или запрещен доступ к ресурсу. Детали

того,

как создавать списки управления доступом и как хранить имена пользовате-

лей и пароли, зависят от программного обеспечения сервера. Вместо того чтобы

иметь отдельный список управления доступом для каждого ресурса, на сервере мо-

жет быть сделана настройка по умолчанию для всех ресурсов в каталоге или для

всех ресурсов сервера. Ресурсы, требующие аутентификации, могут быть размеще-

ны в отдельном каталоге (например, /www/private).

Проверкой полномочий называется процесс применения этих стратегий управ-

ления доступом. При обработке запроса сервер должен определить, является ли за-

прашиваемый ресурс защищенным списком управления доступом. Например, ре-

сурс http://www.bar.com/private/index.html может быть связан с HTML-файлом,

хранящимся по адресу /www/private/index.html. Доступ к каждому подкаталогу

может разрешен только для определенных пользователей. В связи с этим сервер

должен определять стратегию управления доступом для каждого каталога на пути

к запрашиваемому файлу. Если доступ к каталогу ограничен, сервер должен вы-

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

выполнен. В дополнение к проверке имени пользователя сервер может разрешать

или запрещать доступ к ресурсу на основе другой информации, ассоциированной

с HTTP-запросом, такой как имя хоста или IP-адрес запросившего клиента. Одна-

ко реализация стратегии поведения при проверке полномочий, основанная на име-

ни клиента или адресе, является довольно рискованной, поскольку некоторые за-

просы могут быть отправлены от имени прокси-сервера, а не агента пользователя.

На самом деле пользователь, которому отказано в доступе к ресурсу, мог настроить

браузер для отправки запросов через прокси-сервер, которому разрешен доступ

к ресурсу.

Аутентификация HTTP-запросов может существенно повысить нагрузку на

Web-сервер. Сервер должен проверить имя пользователя и пароль для идентифи-

кации пользователя и должен осуществить анализ аутентификационной информа-

ции в каждом каталоге на пути к запрашиваемому ресурсу. При сложных настрой-

ках сервера процесс проверки полномочий обходится достаточно дорого. Нагрузка

может быть снижена за счет выполнения этих функций только по мере необходи-

мости. Например, стратегия поведения для каталога верхнего уровня, например,

/www/public, может предусматривать, что ни один из подкаталогов не требует

проверки прав доступа. Это дает возможность серверу избежать дополнительных

проверок в подкаталогах. Администратор сервера может ограничить проверку пол-

номочий только для небольшого числа особо важных ресурсов, которые могут быть

помещены в особый подкаталог. Это позволит минимизировать накладные расходы

на аутентификацию и проверку полномочий, ограничивая в то же время доступ

к данным там, где это необходимо.

104

Часть

П.

Компоненты программного обеспечения

Web

4.2.3.

Динамическое создание ответов

Помимо доставки статического содержимого, в Web имеются возможности для

динамического создания ресурсов и доступа к ним. Эти возможгюсти отличают

Web от первых сервисов в Internet по передаче файлов. Динамически генерируе-

мые ответы создаются различными способами. Включения на

стороне

серверакрел-

писывают Web-серверу настраивать статические ресурсы с помощью директив, со-

держащихся в файле. В противоположность этому,

серверный

сценарий представля-

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

может выполняться как в адресном пространстве сервера или как отдельный про-

цесс,

который взаимодействует с сервером. Динамическое создание сообщения-от-

вета обеспечивает высокую степень гибкости, но п|)иводит к увеличению нагрузки

на сервер, а также снижает безопасность.

ВКЛЮЧЕНИЯ НА СТОРОНЕ СЕРВЕРА

Создатели Web-содержимого часто осуществляют настройку Web-страницы на

конкретного пользователя, обращающегося с запросом. Например, Web-страница

может отображать текущее время, IP-адрес или имя клиента. Создатель Web-со-

держимого не обладает этой информацией на момент создания HTML-файла. Вме-

сто этого файл может включать в себя директивы или макросы, инструктирующие

сервер вставить информацию в процессе обработки запроса. Отвечая на клиент-

ский запрос, сервер осуществляет синтаксический анализ файла и замещает текст

каждого макроса. Макросы представляют собой специальные теги в файле, кото-

рые интерпретируются сервером. Например, файл может содержать директиву

<!- #echo var="LAST_MODIFIED"—>

которая включает время последней модификации файла в ответ, отправляемый

клиенту. Информация появляется в теле ответа в виде HTML-текста и будет ото-

бражена пользователю. Это никак не связано с включением сервером метаданных

в заголовок HTTP-запроса.

Макросы могут ссылаться на множество разнообразных переменных, содержа-

щих информацию о HTTP-запросе. Помимо простого замещения, макрос может тре-

бовать, чтобы сервер вставил в документ другой файл. Например, документ /www/

foo.html может содержать макрос, который вставляет содержимое другого файла,

/www/infoo.html, в HTML-код сообщения-ответа. Если обобщить, макрос может

инструктировать сервер вызывать программу, указанную в макросе, отличную от

программы, указанной в URL сообщения-запроса. Включения на стороне сервера

предлагают создателям Web-содержания относителыю простой способ настройки их

документов путем внесения незначительных дополнений в HTML-код. Создателю

содержимого при этом не нужно знать о других способах динамического создания

HTML-содержания. Однако серверные включения требуют, чтобы Web-сервер осу-

ществлял синтаксический анализ HTML-файлов и выполнял действия, запрашивае-

мые макросом. Это приводит к большему времени ожидания на стороне пользовате-

ля по сравнению с традиционной загрузкой статического HTML-файла.

Выполнение синтаксического анализа для каждого запроса может привести к не-

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

содержит макросов. Вместо этого сервер определяет, требует ли файл синтаксиче-

ского анализа, основываясь на URL. В соответствии с принятым соглашением, такие

ресурсы имеют расширение .shtml вместо .html. Другим получившим распростране-

ние файловым расширением является .php. Оно принято для страниц, обрабатывав-

Глава

Web-серверы

105

мых PHP (Hypertext Preprocessor или Personal Home Page). PHP представляет со-

бой язык сценариев, который не зависит от платформы, сценарии встраиваются

в HTML-код и обладают более широкими возможностями но сравнению с простым

замещением. Интерпретатор РНР выполняется под управлением Web-сервера, ин-

терпретатор осуществляет синтаксический анализ и обработку файлов. РНР-файл

может содержать данные, отправленные пользователем в HTML-формах. Так, если

пользователь ввел имя и номер телефона, эти переменные мохут быть включены

в HTML-файл, возвращаемый сервером. В РНР также имеются гибкие средства под-

держки работы с базами дагнхых. Еще одним популярным расширением файлов яв-

ляется .asp. Оно принято для Microsoft Active Server Pages (ASP). ASP, подобно

PHP,

встраивает переменные и операторы сценариев непосредственно в HTML-файл.

Однако ASP может использоваться только Web-серверами на платформе Microsoft.

СЕРВЕРНЫЕ СЦЕНАРИИ

Вместо того чтобы встраивать информацию в HTML-файл, некоторые програм-

мы могут генерировать весь ресурс. В этом случае URL в HTTP-запросе соответст-

вует программе, а не документу. Программа может решать различные задачи, такие

как доступ к информации в базах данных или создание ответа, содержание которого

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

по своему принципу аналогична разрешению пользователям «заходить» на сервер и

выполнять программы. Однако при этом имеется несколько важных различий. Вме-

сто прямого доступа к компьютеру сервера, пользователь указывает нужный сцена-

рий и его параметры в HTTP-запросе. Сценарии формируют выходные данные

в формате (например, HTML), который может быть интерпретирован Web-браузе-

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

ответы не отличаются от статических ресурсов за исключением того, что при этом

может увеличиться время ожидания, связанное с выполнением сценария.

Исполнение сценария на сервере также отличается от загрузки программы (на-

пример, написанной на Java) для ее выполнения в Web-браузере. Выполнение про-

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

с браузером и с пользователем. В противоположность этому серверные сценарии

имеют доступ к данным, которые могут быть недоступны где-либо еще. Например,

Web-сервер может активизировать сценарий, выполняющий запрос пользователя

на книги по определенной тематике. Ответ на запрос может вызвать необходи-

мость обращения к данным, содержащим конфиденциальную информацию. Вы-

полнение запроса на клиенте потребовало бы копирования всех этих данных. Кро-

ме того, потребовалась бы программа, способная выполнить поиск. Выполнение

программы как сценария на сервере гарантирует, что программа и данные не будут

незаконно использованы. Программа со временем может быть модифицирована

в случае обнаружения ошибок. В нее могут быть внесены усовершенствования, при

этом пользователям не нужно устанавливать на своих компьютерах новые версии.

Данные также могут быть изменены «незаметно» для пользователя.

Теоретически код, который генерирует динамический ответ, может быть интегри-

рован с профаммным обеспечением Web-сервера. Однако это нежелательно, по-

скольку потребует внесения изменений в профаммное обеспечение сервера каждый

раз,

когда добавляется новая функциональная возможность. Это также требует, что-

бы каждый разработчик приложений был знаком с программным обеспечением сер-

вера. Желательно было бы иметь одну группу программистов, разрабатывающих

программное обеспечение Web-сервера, и другую группу программистов, потенци-

ально более крупную, создающих приложения для динамического создания содер-

106

Часть

П. Компоненты программного обеспечения Web

жания. Четкое разделение программного обеспечения сервера и сценариев имеет

большое значение. Главная задача Web-сервера

—

связать запрашиваемый URL с со-

ответствующим сценарием и передать данные в сценарий. Главная задача сцена-

рия

—

обработать входные данные и создать содержание для клиента. Сервер может

взаимодействовать со сценарием различными способами:

• Отдельный процесс, инициированный сервером. Сценарий может выпол-

няться как отдельный процесс, инициированный сервером для создания за-

прашиваемого ресурса. Наличие отдельного процесса изолирует сервер от сце-

нария, но при этом для каждого запроса приходится затрачивать дополнитель-

ные усилия на создание и уничтожение процесса. Это традиционный подход,

приятый для интерфейса Common Gateway Interface (CGI).

• Программный модуль, выполняющийся в том же процессе. Сценарий может

быть оформлен как отдельный программный модуль, выполняющийся как

часть Web-сервера. Вызов модуля в процессе сервера позволяет избежать до-

полнительных затрат, имеющих место при создании отдельного процесса, и

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

применен в Netscape Server Application Programming Interface (NSAPI), Micro-

soft Internet Server Application Programming Interface (ISAPI), в модуле

Apache mod-perl, a также в сервлетах

}?iWdi

Sun Microsystems.

• Непрерывный процесс, взаимодействующий с сервером. Сценарий может

выполняться в отдельном процессе, который обрабатывает множество запро-

сов в течение длительного периода времени. Сервер взаимодействует с про-

цессом, передавая ему параметры и получая выходные данные. Наличие от-

дельного выполняющегося процесса избавляет от необходимости создавать и

уничтожать процесс для каждого запроса; кроме того, процесс может обслу-

живать взаимодействие с другими сервисами, такими как системы управления

базами данных. Подобный подход реализован в FastCGI [FcgJ.

Разработка методов взаимодействия между Web-серверами и сценариями стала

за последние несколько лет сферой значительной коммерческой активности. Это

привело к появлению большого количества разнообразных интерфейсов приклад-

ного программирования для написания сценариев.

ПЕРЕДАЧА ДАННЫХ В СЦЕНАРИЙ И ИЗ СЦЕНАРИЯ

Отделение сценариев от Web-сервера требует наличия строго определенного

интерфейса для передачи данных между двумя компонентами программного обес-

печения. Первым делом сервер должен определить, что запрашиваемый ресурс

представляет собой сценарий, а не документ. URL, указывающие на сценарии,

обычно содержат символ "?" или подстроку "cgi", "cgi-bin" или "cgibin". Вообще го-

воря, связывание URL со сценарием определяется настройками сервера. Например,

сервер может быть настроен таким образом, что любой URL с определегншхм рас-

ширением (например, .cgi) или размещенный в определенном подкаталоге (напри-

мер,

/www/scripts или /www/cgibin), будет восприниматься как сценарий. После

проверки того, что URL соответствует сценарию, сервер проверяет разрешение на

выполнение сценария. Затем сервер запускает сценарий и ожидает его завершения,

после чего отправляет ответ клиенту.

Наличие четко определенного интерфейса для обмена данными имеет важное

значение для организации совместной работы сервера и сценария. Реализации ин-

терфейса различаются в зависимости от используемой технологии. Тем не менее,

все методы едины в том, что сервер передает входные данные сценарию и получает

Глава 4. Web-серверы

107

от него выходные данные. В качестве иллюстрации рассмотрим подход, используе-

мый в популярном интерфейсе Common Gateway Interface (CGI) [Gun96]. CGI оп-

ределяет интерфейсы для большого числа платформ. Операционные системы отли-

чаются способами, используемыми для обмена данными между приложениями.

Это затрудняет реализацию единого интерфейса, применимого для всех платформ.

Web-сервер на базе UNIX направляет данные сценарию через стандартный ввод и

переменные окружения, а получает данные от сценария через стандартный вывод.

Языки программирования, такие как Perl или С, имеют функции, которые возвра-

щают значения указанных переменных окружения. В последуюш,ем обсуждении

мы сосредоточим внимание на взаимодействии между UNIX-сервером и CGI-сце-

нарием.

Таблица 4.1. Примеры

Тип

Информация 0 сервере

Информация 0 клиенте

Информация 0 запросе

переменных окружения CGI

Переменная

SERVER_NAME

SERVER_SOFTWARE

SERVER_PROTOCOL

SERVER_PORT

DOCUMENT_ROOT

GATEWAY_INTERFACE

REMOTE_ADDR

REMOTE_HOST

CONTENT_TYPE

CONTENT_LENGTH

REQUEST_METHOD

QUERY_STRING

ACCEPT_LANGUAGE

HTTP_USER_AGENT

Пример 1

www.bar.com |

Apache/1.2.6

HTTP/1.0

/www 1

CGI/2.0

10.9.57.188

users.berkelly.edu |

text/html 1

158

GET

namc=Noam+Chomsky |

de-CH

Mozilla/2.0 1

Web-сервер предоставляет сценарию разнообразную информацию, как показано

в таблице 4.1. Информация о сервере содержит имя (доменное имя хоста или IP-ад-

рес),

название и номер версии программного обеспечения сервера, название и вер-

сию протокола, помер порта сервера и корневой каталог для ресурсов, размещенных

на Web-сайте. Информация о клиенте включает в себя IP-адрес и имя компьютера

клиента. Информация о запросе включает тип содержимого запроса, длину запроса

и желательный формат для запрашиваемого ресурса. Другие поля HTTP-запроса

доступны через переменные, имена которых начинаются с HTTP. Например,

HTTP-запрос может содержать заголовок User-Agent, который идентифицирует тин

браузера, сделавшего запрос; эта информация будет доступгюй через переменную ок-

ружения HTTP_USER_AGENT. Аналогично, переменная НТТР_СООК1Е указыва-

ет на cookie, если они включены в HTTP-запрос. Переменные окружения дают воз-

можность сценарию менять свои действия в зависимости от сервера, обратившегося

с запросом клиента, и заголовков запроса. Например, сценарий может прочесть файл

neatdata.txt из корневого каталога /www и преобразовать его содержимое для соз-

108

Часть

II.

Компоненты программного обеспечения

Web

Дания HTML-файла с IP-адресом клиента и приветствием на швейцарском диалекте

немецкого языка.

CGI также предоставляет сценарию способ получать данные от пользователей,

которые вводят их в HTML-формах. Вернувшись к примеру, предположим, что на

Web-странице http://www.bar.com/foo.html отображается поле ввода, где пользо-

ватель может ввести текст и отправить его серверу нажатием кнопки Submit. Пред-

положим, что пользователь ввел "Noam Chomsky" и щелкнул мышью на кнопке

Submit, что заставляет браузер отправить НТТР-занрос GET на ресурс

http://www.bar.com/book.cgi?name=Noam+Chomsky, либо запрос POST с URL

http://www.bar.com/book.cgi, содержимое запроса передается в теле сообщения.

После получения запроса сервер вызывает сценарий /www/book.cgi. В дополне-

ние к установке переменных окружения сервер передает сценарию значения пара-

метров через дополнительную переменную окружения (QUERY_STRING для ме-

тода GET) или через стандартный ввод (для метода POST).

Сценарий просматривает клиентский ввод (если он имеется) и переменные ок-

ружения. При обработке запроса сценарий может взаимодействовать с другими

серверами или базами данных. Например, сценарий /www/book.cgi может выдать

запрос к базе данных для получения информации о книгах, написанных Ноамом

Хомски. При записи сообщения-ответа в стандартный ноток вывода сценарий мо-

жет создать HTTP-заголовки от имени сервера. Например, сценарий может создать

заголовок, в котором указываются на размер и тип тела сообщения (например,

GIF-изображение размером 3576 байтов), или предоставить URL, который переад-

ресует клиента к другой Web-странице. Web-сервер может быть настроен для по-

лучения заголовка ответа, предоставленного сценарием, без модификации; это на-

зывается сценарием без синтаксического анализа заголовка. В других случаях

Web-сервер анализирует выходные данные сценария для включения в них отсутст-

вующей информации (например, заголовка Date с текущими датой/временем) до

пересылки ответа клиенту.

ВЛИЯНИЕ СЦЕНАРИЕВ НА ПРОИЗВОДИТЕЛЬНОСТЬ И БЕЗОПАСНОСТЬ

Выполнение сценариев на сервере оказывает существенное влияние на произво-

дительность и безопасность. При запуске сценария и передаче данных в обоих на-

правлениях потребляются ресурсы сервера. Кроме того, сам сценарий может вы-

полнять вычисления, осуществлять доступ к базам данных, либо связываться

с другими серверами. Эти операции создают задержки ответов на клиентские за-

просы. Рассмотрим пользовательский запрос, который требует взаимодействия

с базой данных, размещенной на другом компьютере, а не на компьютере сервера.

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

компьютером для передачи запроса к базе данных. Ответ задерживается на время,

необходимое для передачи запроса по сети и операций с базой данных. Кроме того,

сценарии обычно пишутся на языках, таких как Perl, которые компилируются во

время выполнения. Затраты на компиляцию сценария увеличивают время ожида-

ния ответа. Предварительно компилируемые языки, такие как С, более эффектив-

ны в этом смысле, по обычно программирование на них более трудоемко, особенно

при работе со строками, что чаще всего встречается в Web-сценариях.

Запуск сценариев на выполнение с помощью URL значительно расширяет

функциональные возможности Web. Однако при написании сценария следует учи-

тывать, какие функции он выполняет и какие системные ресурсы потребляет. В са-

мом худшем случае плохо написанный сценарий может никогда не закончить свою

работу и расходовать значительную долю ресурсов процессора и памяти. Как ре-

Глава

Web-серверы

109

зультат, Web-серверы обычно накладывают ограничения на ресурсы процессора и

память, предоставляемые сценарию. Следует также иметь в виду, что администра-

тор Web-сайта может запретить использование сценариев или наложить ограниче-

ния на круг лиц, которым разрешается устанавливать новые сценарии. Использо-

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

Сценарий может выполнять многочисленные функции, неожидациые для разра-

ботчиков Web-сервера. Сценарий может осуществлять доступ к файлам на компь-

ютере сервера. Плохо написанный сценарий может изменить данные или вернуть

запросившему клиенту информацию, не подлежащую разглашению.

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

предосторожностей, чтобы гарантировать, что пользователь не сможет через сцена-

рий выполнить несанкционированные действия. Рассмотрим пример сценария, ко-

торый дает возможность пользователю вводить произвольные команды для их вы-

полнения на компьютере сервера. Пользователь может с помощью такого сценария

удалить файлы на компьютере сервера или передать пользователю конфиденци-

альную, не предназначенную для него информацию (например, с помощью элек-

тронной почты). Подобных ситуаций можно избежать несколькими способами.

Во-первых, сценарий может быть написан таким образом, чтобы ограничить вводи-

мую пользователем информацию. Например, Web-страница может предоставлять

пользователю возможность выбора из ряда предопределенных действий или ввода

списка ключевых слов вместо команд для выполнения их на компьютере сервера.

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

тельских данных, чтобы избежать выполнения операций, которые дают иесанкцио-

нировагп1ЫЙ доступ к программам или данным. В-третьих, администратор сайта

может ограничить доступ к самим сценариям. Например, сценариям может быть

запрещен доступ к файлам, содержащим важные данные (например, файлу паро-

лей),

и к определенным командам (например, отправка электронной почты или

удаление файлов). Администратор сайта может также принудить сценарий выпол-

няться с теми же правами доступа, которые имеет человек, написавший сценарий,

предотвращая тем самым доступ сценария к файлам, к которым не имеет доступа

автор сценария.

4.2,4. Создание и использование cookies

Cookies дают возможность сохранять информацию о пользователе в течение оп-

ределенного времени, о чем шла речь в главе 2 (раздел 2.6). Web-сайты используют

cookies для отслеживания пользователей и хранения информации о транзакциях,

которые выполняются с помощью многочисленных НТТР-взаимодействий. Coo-

kies обычно создаются, используются и модифицируются сценариями, вызываемы-

ми для динамического создания ответов, а не Web-сервером.

Web-сайт может адаптировать содержание передаваемое пользователю, обра-

тившемуся с запросом. Например, сайт электронной коммерции может возвратить

Web-страницу с персонифицированным приветствием, которое содержит имя

пользователя и рекомендации по возможным покупкам. Отслеживание пользовате-

лей дает возможность Web-сайту создавать профили отдельных пользователей и

накапливать статистику о поведении пользователей при обращениях к сайту, на-

пример, среднее время, проведенное пользователем на сайте. Однако HTTP-запрос

не предоставляет достаточной информации для идентификации пользователей.

Множество пользователей могут просматривать Web-содержимое с одного компь-

ютера или направлять свои запросы через один и тот же прокси-сервер. Кроме