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

Помимо доставки статического содержимого, в Web имеются возможности для динамического создания ресурсов и доступа к ним. Эти возможности отличают Web от первых сервисов в Internet по передаче файлов. Динамически генерируемые ответы создаются различными способами. Включения на стороне cepвepak ред- писывают Web-cepвepy настраивать статические ресурсы с помощью директив, содержащихся в файле. В противоположность этому, серверный сценарий представляет собой отдельную программу, которая создает запрашиваемый ресурс. Программа может выполняться как в адресном пространстве сервера или как отдельный процесс, который взаимодействует с сервером. Динамическое создание сообщения-от- вета обеспечивает высокую стенепь гибкости, по гфиводит к увеличению нагрузки на сервер, а также спижает безопасность.

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

Создатели Web-содержимого часто осуществляют настройку Web-страиицы на копкретпого пользователя, обращающегося с запросом. Например, Web-страница может отображать текущее время, IP-адрес или имя клиента. Создатель Web-содержимого не обладает этой информацией на момепт создания HTML-файла. Вместо этого файл может включать в себя директивы или макросы, инструктирующие сервер вставить информацию в процессе обработки запроса. Отвечая на клиентский запрос, сервер осуществляет синтаксический анализ файла и замещает текст каждого макроса. Макросы представляют собой специальные теги в файле, которые интерпретируются сервером. Например, файл может содержать директиву

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

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

Макросы могут ссылаться на множество разнообразных перемепиых, содержащих информацию о HTTP-запросе. Помимо простого замещения, макрос может требовать, чтобы сервер вставил в документ другой файл. Например, документ /www/ foo.html может содержать макрос, который вставляет содержимое другого файла, /www/infoo.html, в HTML-код сообщения-ответа. Если обобщить, макрос может инструктировать сервер вызывать программу, указанную в макросе, отличную от программы, указанной в URL сообщения-запроса. Включения на стороне сервера предлагают создателям Web-содержания относительно простой способ иастройки их документов путем внесения незначительных дополнений в HTML-код. Создателю содержимого при этом не нужно знать о других способах динамического создания HTML-содержаиия. Однако серверные включения требуют, чтобы Web-ccpBep осуществлял синтаксический анализ HTML-файлов и выполнял действия, запрашиваемые макросом. Это приводит к большему времеии ожидаиия на стороне пользователя по сравнению с традиционной загрузкой статического HTML-файла.

Выполнение синтаксического анализа для каждого запроса может привести к неоправданному увеличению нагрузки сервера, особегшо если большинство файлов не содержит макросов. Вместо этого сервер определяет, требует ли файл синтаксического анализа, основываясь на URL. В соответствии с принятым соглашением, такие ресурсы имеют расширение .shtml вместо .html. Другим получившим распространение файловым расширением является .php. Оио принято для страниц, обрабагывае- мых PHP (Hypertext Preprocessor или Personal Home Page). PHP представляет собой язык сценариев, который не зависит от платформы, сценарии встраиваются в HTML-код и обладают более широкими возможностями по сравнению с простым замещением. Интернретатор PHP выполняется под управлением Web-cepвepa, интерпретатор осуществляет синтаксический Анализ и обработку файлов. РНР-файл может содержать данные, отправленные пользователем в HTML-формах. Так, если пользователь ввел имя и номер телефона, эти переменные мохут быть включены в HTML-файл, возвращаемый сервером. В PHP также имеются гибкие средства поддержки работы с базами данных. Еще одинм популярным расширением файлов является .asp. Оно принято для Microsoft Active Server Pages (ASP). ASP, подобно PHP, встраивает переменные и операторы сценариев непосредственно в HTML-файл. Однако ASP может использоваться только Web-серверами на платформе Microsoft.

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

Вместо того чтобы встраивать информацию в HTML-файл, некоторые программы могут генерировать весь ресурс. В этом случае URL в HTTP-запросе соответствует программе, а не документу. Программа может решать различные задачи, такие как доступ к информации в базах данных или создапие ответа, содержание которого зависит от клиента, обращающегося с запросом. Поддержка выполнения сценариев по своему принципу аналогична разрешению пользователям «заходить» на сервер и выполнять программы. Однако при этом имеется несколько важных различий. Вместо нрямого доступа к компьютеру сервера, пользователь указывает нужный сценарий и его параметры в HTTP-запросе. Сценарии формируют выходные данные в формате (например, HTML), который может быть интерпретирован Web-6pay3e- ром. С точки зрения клиента и пользователя подобные динамически генерируемые ответы не отличаются от статических ресурсов за исключением того, что при этом может увеличиться время ожидания, связанное с выполнением сценария.

Исполнение сценария на сервере также отличается от загрузки программы (па- пример, написанной на Java) для ее выполнения в Web-бpayзepe. Выполнение программы в браузере больше подходит для приложений, которые взаимодействуют с браузером и с пользователем. В противоположность этому серверные сцепарии имеют доступ к данным, которые могут быть недоступны где-либо еще. Например, Web-сервер может активизировать сценарий, выполняющий запрос пользователя на книги но определенной тематике. Ответ на запрос может вызвать необходимость обращения к данным, содержащим конфиденциальную информацию. Выполнение запроса на клиенте потребовало бы копирования всех этих данных. Кроме того, потребовалась бы программа, способная выполнить поиск. Выполнение программы как сценария на сервере гарантирует, что программа и данные не будут незаконно использоваиы. Программа со временем может быть модифицирована в случае обнаружения ошибок. В нее могут быть внесены усовершенствования, при этом пользователям не нужно устанавливать на своих компьютерах новые версии. Данные также могут быть изменены «незаметно» для пользователя.

Теоретически код, который генерирует динамический ответ, может быть интегрирован с программным обеспечением Web-сервера. Однако это нежелательно, поскольку потребует внесения изменений в программное обеспечение сервера каждый раз, когда добавляется новая функциональная возможность. Это также требует, чтобы каждый разработчик приложений был знаком с программным обеспечением сервера. Желательно было бы иметь одну группу программистов, разрабатывающих программное обеспечение Web-сервера, и другую группу программистов, потенциально более крупную, создающих приложения для динамического создания содер- жаиия. Четкое разделение программного обеспечения сервера и сценариев имеет большое значение. Главная задача Web-cepвepa — связать запрашиваемый URL с соответствующим сценарием и передать данные в сценарий. Главная задача сценария — обработать входные данные и создать содержание для клиента. Сервер может взаимодействовать со сценарием различными способами:

•          Отдельный процесс, инициированный сервером. Сценарий может выполняться как отдельный процесс, инициированный сервером для создания запрашиваемого ресурса. Наличие отдельного процесса изолирует сервер от сценария, но при этом для каждого запроса приходится затрачивать дополнительные усилия на создание и уничтожение процесса. Это традиционный подход, приятый для интерфейса Common Gateway Interface (CGI).

•          Программный модуль, выполняющийся в том же процессе. Сценарий может быть оформлен как отдельный программный модуль, выполняющийся как часть Web-сервера. Вызов модуля в процессе сервера позволяет избежать дополнительных затрат, имеющих место при создапии отдельного процесса, и уменьшить требования к системным ресурсам сервера. Подобный подход был применен в Netscape Server Application Programming Interface (NSAPI), Microsoft Internet Server Application Programming Interface (ISAPI), в модуле Apache mod-perl, а также в сервлетах Java Sun Microsystems.

•          Непрерывный процесс, взаимодействующий с сервером. Сценарий может выполняться в отдельном процессе, который обрабатывает множество запросов в течение длительного нериода времени. Сервер взаимодействует с процессом, передавая ему параметры и получая выходные данные. Наличие отдельного выполняющегося процесса избавляет от необходимости создавать и уничтожать процесс для каждого запроса; кроме того, процесс может обслуживать взаимодействие с другими сервисами, такими как системы управленИя базами данных. Подобный подход реализован в FastCGI [FcgJ.

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

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

Отделение сценариев от Web-сервера требует наличия строго определенного интерфейса для передачи данных между двумя компонентами программного обеспечения. Первым делом сервер должен определить, что запрашиваемый ресурс представляет собой сценарий, а не документ. URL, указывающие на сценарии, обычно содержат символ "?" или подстроку "cgi", "cgi-bin" или "cgibin". Вообще говоря, связывание URL со сцеиарием определяется настройками сервера. Например, сервер может быть настроен таким образом, что любой URL с определенным расширением (например, .cgi) или размещенный в определенном подкаталоге (например, /www/scripts или /www/cgibin), будет восприниматься как сценарий. После проверки того, что URL соответствует сценарию, сервер проверяет разрешение на выполнение сценария. Затем сервер занускает сценарий и ожидает его завершения, после чего отправляет ответ клиенту.

Наличие четко определенного интерфейса для обмена данными имеет важное значение для организации совместной работы сервера и сценария. Реализации интерфейса различаются в зависимости от используемой технологии. Тем не менее, все методы едины в том, что сервер передает входпые данные сценарию и получает от него выходные данные. В качестве иллюстрации рассмотрим нодход, используемый в популярном интерфейсе Common Gateway Interface (CGI) [Gun96]. CGI определяет интерфейсы для большого числа платформ. Операционные системы отличаются способами, используемыми для обмена данными между приложениями. Это затрудняет реализацию единого интерфейса, применимого для всех платформ. Web-cepвep на базе UNIX направляет данные сценарию через стандартный ввод и переменные окружения, а получает данные от сценария через стандартный вывод. Языки программирования, такие как Perl или С, имеют функции, которые возвращают значения указанных переменных окружения. В последующем обсуждении мы сосредоточим внимание на взаимодействии между UNIX-сервером и CGI-сце- нарием.

Таблица 4.1. Примеры переменных окружения CGI

Web-cepвep предоставляет сценарию разнообразную информацию, как показано в таблице 4.1. Информация о сервере содержит имя (доменное имя хоста или IР-ад- pec), название и номер версии программного обеспечения сервера, название и версию протокола, помер порта сервера и корневой каталог для ресурсов, размещенных на Web-сайте. Информация о клиенте включает в себя IP-адрес и имя компьютера клиента. Информация о запросе включает тип содержимого запроса, длину запроса и желательный формат для запрашиваемого ресурса. Другие поля НТТР-запроса доступны через неременные, имена которых начинаются с HTTP. Например, HTTP-запрос может содержать заголовок User-Agent, который идентифицирует тип браузера, сделавшего запрос; эта информация будет достунной через переменную окружения HTTP_USER_AGENT. Аналогично, переменная HTTP_COOKIE указывает на cookie, если они включены в HTTP-запрос. Переменные окружения дают возможность сценарию менять свои действия в зависимости от сервера, обратившегося с запросом клиента, и заголовков запроса. Например, сценарий может прочесть файл neatdata.txt из корневого каталога /www и преобразовать его содержимое для соз- дапия HTML-файла с IP-адресом клиента и приветствием на швейцарском диалекте немецкого языка.

CGI также предоставляет сценарию способ получать данные от пользователей, которые вводят их в HTML-формах. Верпувшись к примеру, предположим, что на Web-странице http://www.bar.com/foo.html отображается поле ввода, где пользователь может ввести текст и отправить его серверу нажатием кнопки Submit. Предположим, что пользователь ввел "Noam Chomsky" и щелкнул мышью на кнопке Submit, что заставляет браузер отправить HTTP-запрос GET на ресурс http://www.bar.convbook.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-cepвep может быть настроен для получения заголовка ответа, предоставленного сценарием, без модификации; это называется сценарием без синтаксического анализа заголовка. В других случаях Web-сервер анализирует выходные данные сценария для включения в них отсутствующей информации (например, заголовка Date с текущими датой/временем) до пересылки ответа клиенту.

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

Выполнение сценариев на сервере оказывает существенное влияние на производительность и безопасность. При запуске сценария и передаче данных в обоих направлениях потребляются ресурсы сервера. Кроме того, сам сцепарий может выполнять вычисления, осуществлять доступ к базам дапных, либо связываться с другими серверами. Эти операции создают задержки ответов на клиентские запросы. Рассмотрим пользовательский запрос, который требует взаимодействия с базой данных, размещенной на другом компьютере, а не на компьютере сервера. Сценарий, выполняющийся на компьютере сервера, должен связаться с удаленным компьютером для передачи запроса к базе данных. Ответ задерживается на время, необходимое для передачи запроса по сети и операций с базой данных. Кроме того, сценарии обычно пишутся на языках, таких как Perl, которые компилируются во время выполнения. Затраты на компиляцию сцепария увеличивают время ожидания ответа. Предварительно компилируемые языки, такие как С, более эффективны в этом смысле, но обычно программирование на них более трудоемко, особенно при работе со строками, что чаще всего встречается в Web-сцепариях.

Запуск сценариев на выполнение с помощью URL значительно расширяет функциональные возможности Web. Однако при написании сценария следует учитывать, какие функции он выполняет и какие системные ресурсы потребляет. В самом худшем случае плохо написаиный сценарий может никогда не закончить свою работу и расходовать значительную долю ресурсов процессора и памяти. Как результат, Web-серверы обычно накладывают ограничения на ресурсы процессора и память, предоставляемые сценарию. Следует также иметь в виду, что администратор Web-сайта может запретить использование сценариев или наложить ограничения на круг лиц, которым разрешается устанавливать новые сценарии. Использование сценариев также сопровождается проблемами, связанными с безопасностью. Сценарий может выполнять многочисленные функции, неожиданные для разработчиков Web-сервера. Сценарий может осуществлять доступ к файлам на компьютере сервера. Плохо написанный сценарий может изменить данные или вернуть запросившему клиенту информацию, не подлежащую разглашению.

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

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100