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

Замечание

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

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

HTTP-заголовок

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

Существует режим работы CGI-модулей, при котором программа самостоятельно взаимодействует с клиентом, формируя заголовки. При этом содержимое потока вывода передается в виде "как есть". Разумеется, что это налагает на CGI-программу дополнительную ответственность, но позволяет добиваться интересных результатов.

Формат заголовка приведен в листинге 9.11.

Листинг 9.11. Вид заголовка HTTP

НТТР/1.1 200 Ok

Date: Fri, 14 Jun 2001 23:18:01 GMT

Server: Apache/1.3

MIME-version: 1.0

Last-Modified: Fri, 14 Jun 2001 23:18:00 GMT

Content-Type: text/html

Content-Length: 500

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

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

• HTTP/1.1 — означает название и версию протокола HTTP.
• 200 OK — код, возвращаемый сервером и символизирующий результат выполнения операции. Этот код может иметь значения, приведенные в табл. 9.3.

Таблица 9.3. Некоторые коды результата обработки запроса клиента

Код	Статус выполнения операции
	Операция запроса выполнена успешно
	Запрос клиента принят
	Ошибка запроса
	Запрос не авторизован
	Ресурс требует оплаты
	Доступ закрыт
	Документ запроса не найден
	Внутренняя ошибка сервера (как правило — CGI-модуля)
	Сервер перегружен
	Сервер временно недоступен

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

При создании CGI-программ вам потребуются коды 200 и, возможно, 503. Остальные коды идентифицируют исключительные ситуации.

• Date: Fri, 14 Jun 2001 23:18:01 GMT — дата обработки запроса.
• Server: Apache/1.3 — марка используемого Web-сервера.
• MIME-version: 1. 0— тип используемой MIME.
• Last-Modified: Fri, 14 Jun 2001 23:18:00 GMT — дата последней модификации документа.
• Content-Type: text/htmi — тип отсылаемых данных.
• Content-Length: 500 — длина содержимого ответа.

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

Режим прямого вывода

Как уже отмечалось, спецификацией CGI предусмотрен режим работы Web-сервера, позволяющий напрямую выводить ответ, минуя процедуру автоматического добавления заголовков. Это так называемый nph-режим (non parsed headers). Для его включения достаточно имя файла — CGI-модуля сделать начинающимся с выражения nph-. Например — nph-module.exe. При работе в этом режиме все заголовки необходимо формировать самостоятельно, а в обычном режиме — нужно лишь указать тип посылаемых данных.

Отправка на сервер данных различного типа. Передача файлов

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

В этом случае все содержимое POST-запроса объявляется МIMЕ-типом multipart/form-data. Этот тип данных предназначен для передачи в рамках одного запроса данных нескольких типов.

POST-запрос при этом состоит из нескольких частей, которые представлены простыми типами и разделяются с помощью ключевого параметра boundary.

Ранее, в гл. 7, посвященной формам, описание возможностей установки типов передаваемых на сервер данных было опущено, поскольку все формы, кроме как для отправки простого текста не используются и по умолчанию передают содержимое типа text/plain. Исключение составляет лишь форма для отправки файлов. При одновременном их наличии на странице необходимо не только знать тип, но и уметь выделять содержимое каждого поля. Рассмотрим все это на примере.

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

Листинг 9.12. Код HTML-документа, предоставляющего возможность для отправки файла на сервер

<HTML>

<FORM action="resume.exe" method="POST" enctype="multipart/form-data">

<Р>Укажите свое имя<ВК>

<INPUT type="text" name="name"XBR>

<Р>Укажите свою фамилию<ВR>

<INPUT type="text" narae="lastname"><BR>

<Р>Введите, пожалуйста, путь и название файла, в котором содержится отправляемое резюме.

<INPUT type="file" name="resumefile"><BR>

<P><INPUT type="Submit" value="Отправить"><INPUT type="Reset" value="Сброс">

</FORM>

</HTML>

Рис. 9.3. Отображение Web-страницы

Отображение такого HTML-документа приведено на рис. 9.3.

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

Листинг 9.13. Содержимое HTTP-запроса (включая заголовок)

Content-Type: multipart/form-data;

boundary=-------7dl21c31450

----------------------------7dl21c31450

Content-Disposition: form-data; name="name"

Sergey

-------------------------------7dl21c31450

Content-Disposition: form-data; name="lastname"

Podolsky

-------------------------------7dl21c31450

Content-Disposition: form-data; name="resumefile";

filename="C:\MoM документы\гезшпе.с1ос" Content-Type: application/msword

Содержимое файла

-----------------------------7dl21c31450--

Как видим, запрос состоит из нескольких частей, которые разделены одинаковой строчкой, указанной в параметре boundary заголовка HTTP (дополнительно, к этому параметру слева дописываются две горизонтальные черты). В конце запроса также находится указанная строка, но теперь уже вслед за ней стоят две горизонтальные черты.

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

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

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

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

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

1. Прочитать из потока ввода число символов, которое хранится в переменной Окружения CONTENT_LENGTH.

2. Определить, какое сочетание символов является разделителем частей запроса. Это делается путем выделения подстроки, с которой начинается тело запроса и которая заканчивается первым пробелом в первой строке (помните, что в листинге 9.13 представлен запрос полностью, а в поток ввода, заголовок (первая строка) не посылается).

3. Путем "отсечения" нужного числа частей тела запроса выделяется необходимый блок. Данные элементов формы посылаются в порядке их следования на Web-странице, поэтому, зная код HTML-документа, содержащего исходную форму, можно легко пропустить нужное число составляющих запроса, чтобы получить доступ к части формы, содержащей файл. Далее, по значению, установленному в поле value, получаем путь и имя файла.

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

5. На диске сервера создается новый файл в некотором каталоге.

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

7. Файл закрывается, и производятся дальнейшие операции.

"Вытягивание" информации или Pull-метод

Этот метод позволяет указывать браузеру необходимость загрузки заданного ресурса через заданный интервал времени посредством введения перед заголовком дополнительной директивы Re fresh: время; 1жъ=адрес, где время указывается в секундах, а адрес — это обычный URL.

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

Листинг 9.14. Пример использования метода Pull

Begin

writeln('HTTP/1.1 200 Ok');

writeln('Refresh:10; URL=http://localhost/');

writeln('Content-Type: text/html');

writeln('');

writeln('<HTML>');

writeln('<H1> Адрес страницы изменился на www.someplace.com</Hl>'};

writeln('</HTML>');

end.

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

Если указываемый адрес будет таким же, что и у самого загруженного документа, то страница будет перезагружаться бесконечно (в случае динамического формирования страницы, на определенном этапе строку Refresh можно опустить и перезагрузка оборвется).

Получение информации о клиенте

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

Рассмотрим их более подробно.

Тип агента пользователя (браузера)

Указывается в переменной HTTP_USER_AGENT. В ней содержится как название, так и версия браузера. Наиболее распространенными программами просмотра на сегодняшний день являются Microsoft Internet Explorer и Netscape Navigator. Вот какую информацию сообщают о себе пятая и шестая версии этих программ соответственно:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)

И

Mozilla/5.0 (Windows; U; Win98; en-US; m!8) Gecko/20001108 Netscape6/6,0.

Как видим, выражения в скобках дополнительно указывают марку операционной системы клиента и некоторые другие сведения. Собирая эти сведения, можно определять тип содержимого страницы, которое может быть послано клиенту. Например, Netscape Navigator не поддерживает стилевой атрибут hover для ссылок, существуют различия и в поддержке графических возможностей JavaScript. Кроме того, сравнивая отображения одинаковых страниц в разных браузерах, можно заметить различия, которые необходимо учитывать. Многие Web-дизайнеры, при использовании языка JavaScript для организации интерфейса, проверяют тип браузера непосредственно в режиме выполнения скрипта. Это приводит к тому, что браузер загружает код, отвечающий за различные варианты поведения, но интерпретирует только тот, который предполагает сценарий JavaScript. При этом, увеличивается время на загрузку каждой страницы. Более оптимально это делать непосредственно на стадии HTTP-запроса, сокращая время на загрузку и интерпретацию документов.

Дата добавления: 2014-12-29