Для работы с информацией, распределенной по Internet предложен протокол прикладного уровня HTTP (HyperText Transfer Protocol), специально разработанный для обмена гипертекстовыми данными. Протокол используется в WWW с 1990 года. Данный протокол позволяет реализовать набор методов доступа, базирующихся на спецификации Универсального Идентификатора Ресурсов (Universal Resource Identifier), применяемого в форме Универсального Локатора Ресурсов (Universe Resource Locator) или Универсального Имени Ресурса (Universal Resource Name).
Сообщения по сети при использовании протокола HTTP, передаются в форме, схожей с форматом почтового сообщения Internet (RFC822) или с форматом сообщений MIME (Multiperposal Internet Mail Exchange). HTTP используется для взаимодействия программ-клиентов с программами-шлюзами, разрешающими доступ к ресурсам электронной почты Internet (SMTP), спискам новостей (NNTP), файлам FTP, системам Gopher и WAIS. Протокол разработан для доступа к этим ресурсам посредством промежуточных программ-серверов (proxy), позволяющих без потерь передавать информацию между различными информационными службами. Протокол реализует принцип “запрос/ответ”, при котором запрашивающая программа или клиент инициирует взаимодействие с отвечающей программой-сервером и посылает запрос, включающий в себя информацию о методе доступа, адресе URI, версии протокола и данных клиента, а также, возможно, тело сообщения клиента. Ответ сервера включает строку состояния, содержащую версию протокола, и код возврата. Одна и та же программа может выступать как в роли сервера, так и в роли клиента, что собственно и происходит при использовании proxy-серверов.
При работе в Internet для обслуживания HTTP запросов используется 80-й порт TCP/IP. Обычно клиент устанавливает соединение и ждет ответа сервера, а после отправки ответа сервер инициирует разрыв соединения. Таким образом, при получении сложных гипертекстовых страниц соединение может устанавливаться несколько раз.
После установки соединения программа-клиент посылает серверу запрос, который может иметь одну из двух форм: полный запрос и простой запрос. Простой запрос содержит метод доступа и запрос ресурса, например:
GET http://polyn.net.kiae.su/
В этой записи слово GET обозначает метод доступа – “получить данные”, а строка http://polyn.net.kiae.su/ – это запрос ресурса. Клиенты, способные поддерживать версии протокола выше 0.9, должны пользоваться полной формой запроса. В полной форме имеется строка запроса, несколько заголовков (заголовок запроса или общий заголовок) и, возможно, тело обозначения ресурса. В форме Бэкуса-Наура это можно записать так:
<Полный запрос> := <Строка Запроса>
(<Общий заголовок>|<Заголовок запроса>|
<Заголовок обозначения ресурса>)
<символ новой строки>[<тело ресурса??????>]
Квадратные скобки обозначают необязательные элементы заголовка. Строка запроса – это, практически, и есть простой запрос ресурса с тем отличием, что здесь можно указывать различные методы доступа и за запросом ресурса следует указывать версию протокола. Например для вызова внешней программы можно использовать следующую строку:
POST http://polyn.net.kiae.su/cgi-bin/test HTTP/1.0
В данном случае используется метод POST и протокол версии 1.0. Сегодня в практике World Wide Web реально используются только три метода доступа: POST, GET и HEAD.
GET – метод, позволяющий получить данные в форме URI. Если ссылка указывает на программу, то возвращается результат выполнения этой программы, а не ее текст. Дополнительные данные, которые надо передать для обработки, кодируются в запрос ресурса. Имеется разновидность метода GET – “условный GET”, при котором сервер ответит на запрос только если будут выполнены условия передачи. Это позволяет разгрузить сеть, избавив ее от передачи ненужной информации. Условия указываются в поле “if-Modified-Since” заголовка запроса. При методе GET в поле тела ресурса возвращается собственно затребованная информация, например, текст HTML-документа (см. ОСС 15/95).
Метод доступа HEAD работает аналогично GET, но не возвращает тело ресурса, и используется для получения информации о ресурсе, а также для тестирования гипертекстовых ссылок.
Метод POST разработан с целью передачи большого объема информации и используется для аннотирования существующих ресурсов, посылки почтовых сообщений, работы с формами интерфейсов к внешним базам данных и внешних исполняемых программ. В противоположность GET и HEAD при методе POST передается тело ресурса, которое собственно и является информацией. В первых версиях протокола были определены и другие методы доступа (например, DELETE – удаление ресурса), которые, однако, не нашли применения. Многие функции, возлагаемые на эти методы, можно теперь успешно выполняются через POST.
В обеих формах запроса важное место занимает форма запроса ресурса, кодируемая в соответствии со спецификацией URI или URL применительно к World Wide Web. При обращении к серверу можно использовать как полную форму URL так и упрощенную. Полная форма содержит тип протокола доступа, адреса сервера и ресурса на сервере.
Однако, такой адрес реально нужен только для работы через промежуточный сервер, способный пересылать запросы. При обращении к первичному серверу клиент может опускать протокол и адрес, устанавливая взаимодействие с сервером по адресу, указанному в URL и в порту 80, задавая только путь от корня сервера.
Ответ сервера, как и запрос, может быть упрощенным или полным. При упрощенном ответе сервер возвращает только тело ресурса (например, текст HTML документа), а при полном – строку состояния (Status-Line), общий заголовок, заголовок ответа, заголовок ресурса и тело ресурса. В форме Бэкуса-Наура это будет выглядеть следующим образом:
<Полный ответ> := <Строка состояния> (<Общий заголовок>|<Заголовок ответа>|<Заголовок ресурса>)
<символ новой строки>[<тело ресурса>]
Строка состояния состоит из версии протокола, кода возврата и краткого его описания, например: “HTTP/1.0 200 Success”. Коды возврата HTTP серверов делятся на: информационные сообщения (1хх); сообщения успешного выполнения запроса (2хх); сообщения переадресации(3хх); ошибки клиента (4хх); ошибки сервера (5хх). Заголовок ответа сервера может состоять из адреса URI запрашиваемого ресурса, и/или наименования программы сервера, и/или кода идентификации для работы в защищенном режиме. Заголовок ресурса по составу полей является общим как для запроса клиента, так и для ответа сервера и состоит из разрешения на метод доступа, типа кодировки тела ресурса, длины тела ресурса, типа ресурса, времени действия данной копии ресурса, времени последнего изменения ресурса и расширения заголовка.
Если в заголовке ответа сервера указано предложение Location, то требуемый ресурс находится по другому адресу и его надо запросить заново. Такая процедура называется перенаправлением, которое может задаваться следующим образом:
Location: http://apollo.polyn.kiae.su/risk/riskform.HTML
Имя и версия сервера указываются в поле Server. При использовании сервера Церна данное поле будет выглядеть так:
Server: CERN/3.0 libwww/2.17
В заголовке может встречаться и поле контроля доступа WWW-Authenticate, которое определяет способ доступа к закрытым ресурсам, выглядящее, например, следующим образом:
WWW-Athenticate: Basic realm=”WallyWorld”
Кроме этих полей в заголовке могут встретиться и другие, определяющие содержание тела передаваемого ресурса. Эти поля относятся к заголовку ресурса, но при рассмотрении ответа сервера они встречаются вперемешку с общими полями. Поле Allow определяет разрешенные методы доступа к ресурсу:
Allow: GET, HEAD
Поле Сontent-Encoding определяет тип кодирования передаваемого ресурса:
Content-Encoding: x-gzip
В данном случае указывается, что ресурс является файлом, упакованным в формате zip. Обычно ресурсы хранятся в виде, указанном в данном поле, и при получении клиент должен обеспечить их преобразование в приемлемый для отображения вид. Это, своего рода, предобработка данных, которая базируется, обычно, на MIME-типах. Например, такая предобработка используется в компьютерах без достаточного объема видеопамяти. Для ПК с 512 Кбайт памяти на видеоадаптере используют предобработку для преобразования картинок, содержащих 256 цветовых оттенков в 16. Если этого не делать, можно наблюдать интересный эффект: при работе с программами Chimera и Mosaic 256 цветные картинки удваиваются, и, вместо одной, на экране отображаются сразу две картинки. Это связано с тем, что для 256 цветов нужно ровно в два раза больше памяти, чем для 16-ти.
Другим полем, порождающим ошибки отображения, является поле Content-Length, которое содержит размер передаваемого ресурса. Это поле указывается как клиентом – при работе по методу POST, так и сервером – при ответе на запросы клиентов. В ранних версиях программ-серверов может возникать ошибка, вызванная возможностью вставки сервером в текст ресурса другой информации. Например, сервер NCSA (1.3) позволяет вставлять в текст HTML-документов фрагменты текста из других файлов при помощи выражений типа:
В данном случае, речь идет об общей заставке для всех документов некоторого раздела. На сервере, в директории документов, хранится файл одного размера, но после выполнения подстановки размер файла увеличивается, однако, сервер сообщает клиенту старый размер файла. Новые программы-клиенты (Netscape, Mosaic) неправильно обрабатывают такой ответ, и информация не отображается.
Поле Content-Type определяет тип информации, передаваемой сервером. Наиболее часто используются типы text/play (простой тест) и text/HTML (документ в формате HTML). Для сокращения трафика по сети существует несколько полей, указывающих время отправки сообщения и срок годности ресурса.
Поле Referer используется для указания местоположения ресурса, из которого была осуществлена ссылка на данный ресурс. Это поле – мечта любого администратора базы данных на сети, при помощи него можно определить в каких WWW страницах прописан ваш сервер. От этого зависит количество обращений к серверу, “качество” пользователей и время отклика на информацию, размещаемую на сервере. При необходимости можно связаться с администратором этого сервера и уведомить его об изменениях на вашем сервере.
Завершая обсуждение протокола HTTP и способов его реализации, нужно отметить, что в качестве широкодоступного информационного ресурса система WWW уже состоялась, и следующий шаг – это серьезные коммерческие применения. Однако для этого необходимо еще внедрить в практику защищенные протоколы обмена, базирующиеся на HTTP.
