HTTP-основной протокол Web

Когда вы путешествуете по Web, броузер на "заднем" плане обменивается сооющениями с серверами Web, используя протокол HTTP. Всякий раз при переходе по гиперсвязи от одного ресурса к другому броузер обращается к HTTP для доступа к серверу, хранящему необходимую информацию. Чтобы разобраться, как идёт обмен документами Web при использовании HTTP, необходимо сперва изучить различные типы документов. Как можно предположить, существует ряд стандартов, определяющих форматы документов. В данном случае форматы документов Web задаются спецификацией MIME. 

 

Понятие MIME

MIME является технической спецификацией, описывающей передачу мультимеддиа-данных с использованием почтовых стандартов Интернет. До того как MIME начали использовать в Web, спецификация, описывающая синтаксис текстовых сообщений для обмена данными между компьютерами (e-mail), уже существовала. Однако передача только текстовых сообщений накладывала ограничения на передачу мультимедия-данных. Полностью стандарты передачи те5стовых сообщений описаны в документе RFC 822 (D. H. Crocker, Standart for the Format of ARPA Internet Text Message, August 1982).
RFC 822 описывает формат текстовых сообщений, передаваемых от одного компьютера к другому. В данном документе не рассматриваются такие типы сообщений, как аудио, видео или графическая информация. Кроме того, RFC 822 не предполагает использование кодовых страниц, отличных от ASCII (US-ASCII). Итак, поскольку в RFC 822 не описана работа с графической информацией, текстами на японском языке и т.д., понадабилась дополнительная спецификация для передачи данных Web любого типа по Интернет.
MIME определяет форматы графических, звуковых, двоичных и видеофайлов, файлов приложений и др. Фактически, используб MIME, можно определить свой формат файла и использовать его при работе с сервером Web (при условии, что сервер может работать с данным форматом).

Примечание: Мы будем рассматривать сервер Web как сервер HTTP, совместимый с версией HTTP 1.0. В настоящее время это наиболее распространённый протокол в Web, однако уже существует версия HTTP 1.1.

Использование MIME в WEb

Как известно, Web состоит из миллионов гиперсвязанных документов. Каждый документ может включать в себя дополнительные ссылки на файлы с графикой, аудио, видео, текстовой информацией и т. д. Когда сервер Web посылает броузеру по Интернет какой-либо файл или документ, он включает в него информацию о типе файла в заголовок MIME. Программа, принимающая данный файл, использует заголовок для идентификации типа файла. В общем случае заголовок представляет собой дополнительную информацию, вставляемую в начало файла (тело объекта). Тело объекта состоит из содержимого оригинального файла или документа, посланного сервером. Далее вы увидите, что возможны случаи, когда программа посылает только заголовок. Кроме того, при использовании MIME вы можете включать в тело объекта несколько документов и посылать их одновременно.

Типы и расширения MIME

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

Тип MIME Расширение MIME
text
text
text
text
multipart
multipart
multipart
multipart
application
application
application
application
application
application
image
image
image
image
audio
audio
video
video
http
plain
richtext
tab-separated-values
digest
form-data
header-set
mixed
activemessage
mac-binhex40
mathematica
msword
postscript
wordperfect5.1
ipeg
gif
ief
tiff
basic
32kadpcm
mpeg
quicktime

Тип и расширение MIME указываются в поле заголовка Content-Type (тип содержимого), предшествующего сообщению, посылаемому по Интернет от сервера Web к броузеру. Для того чтобы разобраться, как используется такая информация, необходимо сперва изучить, какие компоненты Web используют MIME.
Броузеры и серверы Web используют тип и расширения MIME. Когда сервер Web готовит файл для передачи броузеру, обычно тип и расширение MIME, указывается в расширении названия файла. Затем сервер посылает данную информацию броузеру. Кроме того, сервер Web использует поле "тип содержимого" заголовка MIME для подтверждения того, что используется формат MIME. Например, это может выглядеть так:

Content-type: application/msword

В данном случае типом MIME является application (приложение), а расширением - msword (сокращение от Microsoft Word). Таким образом, броузер знает, что ему передан документ Word.

Подробнее о типах MIME

Рассмотрим типы MIME более детально. Согласно таблице 3.1, тип text MIME представляет текстовую информацию в виде набора символов определённой кодировки и описание формата текста. Примерами такого типа MIME являются обычный текст ASCII, RTF (Rich Text Format), HTML и другие.

  • Приложения используют выpажение multipart для объединения нескольких документов, возможно, с различными типами данных, в одном сообщении. Например, для того чтобы уменьшить число сообщений, проходящих между сервером и броузером, сервер может объединять в одном теле объекта несколько документов. Сервер Web добавляет к телу объекта заголовок "multipart/mixed" и посылает сообщение по Интернет к броузеру. Когда броузер принимает данное сообщение, он изучает заголовок и определяет, из каких типов документов оно скомпоновано. В данном случае сервер должен позаботиться о разделении документов, чтобы клиент ясно видел начало и конец каждого из них.
  • Приложения используют тип application для передачи данных приложений или двоичных данных (исполняемых модулей программ) по Интернет.
  • Приложения используют тип message для встраивания существующих почтовых сообщений. Например, если вам необходимо ответить на сообщение e-mail и включить в него оригинал принятого сообщения, то необходимо применять данный тип MIME.
  • Значение image используется при передачи неподвижных изображений (картинок). В Web вы встретите много узлов, где используется данный тип.
  • Значение audio для типа MIME означает звуковые файлы.
  • Приложения используют тип video для передачи видеоизображений, возможно, со звуком как частью составного формата видеоданных.

Создатели MIME предусмотрели в нём возможности расширения. Как только появляются новые пары тип/расширение, это сразу находит отражение в данном стандарте.
Как вы видите, MIME является важной частью Web, так как передача гипертекстовых документов (включающих в себя мультимедиа) есть основной фактор, отличающий данные Web от данных Интернет.

Принципы работы HTTP

В отличие от таких протоколов, как FTP, обеспечивающих неразрывное соединение до тех пор, пока не произойдёт ошибка или не будет подан сигнал к завершению соединения, HTTP работает по-другому. Для каждой операции HTTP броузер и сервер устанавливают, а затем разрывают его. Например, когда вы подключаететсь к узлу Web, броузер и сервер организуют соединение, позволяющее серверу передать HTML-страницу данного узла броузеру. После того как броузер принимает файл, сервер разрывает соединение. Если после анализа HTML-страницы выясняется, что необходимо передать графический файл, соединение необходимо устанавливать заново.
Одна операция HTTP часто называется транзакцией. HTTP использует соединение 
TCP/IP, устанавливаемое на период транзакции. Ни броузер (клиент), ни сервер не хранят информацию даже о последнем соединении. Таким образом, путешествие по Web представляет собой ряд последовательных транзакций HTTP. Когда вы щёлкаете мышью на гипертекстовой ссылке, броузер переносит вас с одного узла на другой. Поскольку вы можете в любой момент перейти на другой узел или выйти из программы-броузера, сервер всегда первый разрывает соединение. Если вы остаётесь, сервер просто устанавливает новое соединение. В случае ухода с узла ему ничего не нужно делать - соединение было разорвано ранее. Такой стиль работы позволяет серверу быстрее переходить к обслуживанию других клиентов, что увеличивает эффективность его работы.
Недавно появилась технология кэширования соединения, когда сервер не разрывает связь немедленно после ответа клиенту. Кэшируя соединение, сервер может очень быстро восстановить его, если клиент решит побродить по данному узлу. Тем более, что зачастую на страницах любоого узла гораздо больше локальных ссылок.

HTTP поддерживает динамические форматы

Используя HTTP, клиенты и серверы определяют форматы документов. Это означает, что при подключении к серверу броузер первым делом высылает ему список доступных ему форматов данных. Сервер после этого старается отвечать ему, используя только такие форматы. В таком случае сервер и клиент могут использовать собственнын форматы данных.
Когда сервер посылает документ Web, он может включить в него информацию о файле (так называемую метаинформацию) в заголовок HTTP. Программа, принимающая данные может в свою очередь использовать данный заголовок для правильной их интерпретации. Таким образом, принимающая сторона получает сообщение, описывающее входящие данные.

Информация заголовка HTTP

Заголовок HTTP хранит информацию о тех объектах, которые приложения передают по Web. Используя информацию данного заголовка, программы договариваются о форматах данных для передаваемых объектов. Если приложение не может распознать информацию заголовка HTTP, большинство их просто игнорируют её. Поскольку приложения игнорируют неизвестные форматы, вы можете смело тестировать новые протоколы Web без нарушения целостности HTTP. Вы так же не можете нарушить работу HTTP, используя неизвестные форматы данных.

Читабельность HTTP

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

HTTP - общий протокол

Сообщения HTTP представляют собой запросы клиента к серверу и ответы сервера клиенту. Существуют два типа подобных сообщений: простые (simple) и полные (full).
Сообщения HTTP, такие как Full-Request и Full-Response, используют стандарный формат сообщений (см. RFC 822). Такой формат может включать в себя дополнтельные поля заголовка и тело объекта (документа). Формат сообщений HTTP является стандартным, поскольку форматы данных в сообщениях не зависят от данного протокола. Другими словами, HTTP не интересует содержимое тела объекта.
Сообщения типа Simple-Request и Simple-Response не допускают использования заголовка и ограничены только данными из тела объекта. Не рекомендуется использовать такой формат сообщений, так как сервер не может определить тип данных, содержащийся внутри сообщения. В свою очередь броузер тоже вынужден пытаться распознавать формат данных. 

Три основные операции HTTP

Используя HTTP, приложения выполняют три основные операции: поиск, извлечение и проверку. При поиске объекта Web-программы применяют HTTP для указания URL объекта на сервер. Если объект существует, приложение использует HTTP, чтобы получить его. После окончания данной операции HTTP сообщает о её статусе. Другими словами, HTTP передаёт программе информацию о том, успешными или неудачными были операции поиска/извлечения данных. В следующих разделах мы рассмотрим все три операции подробнее.

Поиск информации

HTTP основан на операциях запроса клиента и ответа сервера. Клиент (запрашивающая сторона) устанавливает TCP\IP-соединение с сервером (отвечающая сторона), посылая сообщение о запросе на соединение по Интернет к серверу. Если сервер доступен, он принимает данное сообщение от клиента и устанавливает соединение.
Когда вы используете броузер для поиска информации по Web, он передаёт ваш запрос на сервер, где хранятся искомые данные. После того, как броузер и сервер устанавливают соединение, броузер посылает сообщение запрос, в котором содержится информация о методе запроса, URI (Uniform Resourse Identifier), версии протокола и сообщение MIME. В сообщении MIME указываются параметры запроса, информация о клиенте и тело объекта.

Извлечение информации

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

Информация о статусе соединения

Когда ваш броузер пытается подключиться к серверу или извлечь (скопировать) информацию, в окне статуса соединения можно наблюдать за всеми фазами процесса. Сообщения о статусе объекта позволяют определить размер информации, необходимой для копирования, а также начало процесса извлечения данных. Используя такую информацию, вы можете при необходимости прервать процесс копирования. Кроме того, предоставляется более полная информация о попытках поиска информации (в главе "Классы ответных кодов HTTP" коды статуса тнформации будут описаны подробнее). Коды статуса обычно выводятся в соответсвующем окне броузера. 

Четыре этапа транзакций HTTP

Перед тем как клиент и сервер смогут обмениваться данными, им необходимо сперва установить соединение. В Интернет это делается с использованием TCP/IP. Далее клиент запрашивает данные у сервера, а сервер отвечает ему и передаёт необходимую информацию. Клиенты и серверы используют HTTP для выполнения таких операций. Кроме того, подобное соединение устанавливается на время только одной транзакции и далее закрывается сервером по её окончании. Теперь попробуем рассмотреть все четыре этапа транзакции более подробно в следующих разделах.

Шаг 1: Устанавливаем соединение

Перед тем как обменяться информацией, клиент и сервер должны сперва установить соединение TCP/IP. Как известно, Интернет использует набор протоколов TCP/IP для организации взаимодеёствия компьютеров. Чтобы отличать протоколы, приложения используют для каждого из них уникальные номера. Общие протоколы, такие как FTP и HTTP, используют "хорошо известные" номера портов. Стандартным значением порта HTTP является 80, хотя сервер и клиент могут работать и по другому номеру. В таблице 3.2 приведены значения портов для наиболее известных протоколов Web и Интернет.

File Transfer Protocol (FTP)
TELNET Protocol
Simple Mail Transfer Protocol (SMTP)
Trivial File Transfer Protocol
Gopher Protocol
Finger Protocol
HTTP Protocol
21
23
25
69
70
79
80

Табл. 3.2. Стандартные значения номеров портов для Интернет.

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

Шаг 2: Запрос клиента

Каждый запрос клиента, передаваемый на сервер Web, начинается с метода, за которым следует URL объекта. Клиент дополняет данную информацию версией протокола HTTP, далее следует символ возврата каретки и перевода строки (CRLF), за которым могут идти данные. В конце броузер ещё раз добавляет CRLF.
Метод HTTP представляет собой команду клиента, указывающую на цель запроса к серверу. Такой метод соответствует ресурсам Web (определяемых URL). Клиент также указывает свою версию протокола HTTP, например HTTP 1.0. Все они вместе - метод, URL и версия протокола HTTP - входят в состав строки запроса (Request-Line).
Клиент использует поле заголовка запроса для указания информации о запросе и о себе. Чуть позже мы рассмотрим поля заголовка запроса подробно в главе 
"Поля заголовка запроса". Тело объекта представляет собой обычные данные в формате 8 бит - 1 байт.

Шаг 3: Ответ сервера

После того как сервер Web принял и обработал сообщение-запрос, он отвечает сообщением-ответом HTTP. Такое сообщение всегда начинается с версии протокола HTTP, затем идут код статуса и тема ответа (3 цифры), CRLF и дополнительная информация с соответсвующим заголовком. В конце сервер добавляет CRLF, за которым может следовать тело объекта.
Код статуса представляет собой трёхзначное число, описываеющее, может ли сервер принять и удовлетворить запрос пользователя. Тема ответа - это короткое текстовое описание кода статуса. Более подробно они будут описаны далее. Версия HTTP, код статуса и тема ответа вместе составляют строку статуса (status line)
Заголовок ответа может содержать информацию о запрашиваемом ресурсе, а также соответствующие определения MIME. Когда сервер Web посылает заголовок ответа клиенту, обычно он совпадает с заголовком, принятым от клиента. Далее мы подробнее рассмотрим форматы заголовков. Как и ранее, тело объекта представляет собой обычные данные в формате 8 бит - 1 байт.

Шаг 4: Сервер разрывает соединение

Прерогативой сервера является разрыв соединения TCP/IP с клиентом после обработки его запроса. Однако как сервер, так и клиент должны отслеживать незаланированные разрывы соединения. Другими словами, если вы щёлкаете на кнопке Stop вашего броузера, он должен закрыть соединение. Кроме того, если произошла поломка одного из компьютеров, другой должен определить это и корректно завершить работу. В любом случае, закрытие соединения всегда приводит к разрыву текущей транзакции, вне зависимости от её статуса. 
Первая цифра кода статуса НТТР определяет класс кода ответа. Существует пять возможных значений для первой цифры (от 1 до 5):

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

    Каждый из пяти классов содержит группу значений статуса кода. В таблице (см. ниже) перечислены значения статуса кода для НТТР 1.0 и 1.1 и соответсвующие темы ответов. Темы ответов представляют собой рекомендованные значения и любой сервер может заменить их другим текстом без ущерба для НТТР. Вам могут повстречаться не все коды статуса из данной таблицы. Но это говорит лишь о том, что сервер может обрабатывать все коды статуса, а может и не все.

    Код статуса Тема ответа
    200 OK
    201 Успешная команда POST
    202 Запрос принят
    203 Запрос GET или HEAD выполнен
    204 Запрос выполнен, но нет содержимого
    300 Ресурс обнаружен в нескольких местах
    301 Ресурс удалён навсегда
    302 Ресурс отсутствует временно
    304 Ресурс был изменён
    400 Плохой запрос от клиента
    401 Неавторизованный запрос
    402 Необходима оплата за запрос
    403 Доступ к ресурсу запрещён
    404 Ресурс не найден
    405 Метод неприменим для данного ресурса
    406 Недопустимый тип ресурса
    410 Ресурс недоступен
    500 Внутренняя ошибка сервера
    501 Метод не выполнен
    502 Неисправный шлюз либо перегрузка сервера
    503 Сервер недоступен/тайм-аут шлюза
    504 Вторичный шлюз/тайм-аут сервера

    Для того чтобы обозначить гипертекстовую ссылку в документе Web, используется специальный элемент HTML, т.н. анкер (anchor - якорь). Фактически анкер HTML представляет собой тег, встраиваемый в документ Web и обозначающий ссылку на URL, которую броузер связывает с определённым текстом либо графическим изображением. URL необходим, поскольку он информирует броузер об адресах гиперсвязанных ресурсов. Другими словами, анкер содержит URL ресурса и соответствует гипертексту либо картинке.

    Абсолютные и относительные URL

    Когда вы встречаете слово гипертекст, оно обозначает ссылку. Web представляет собой огромный лабиринт гиперсвязанных документов. Когда создаётся документ Web, его автор вставляет в него ссылки к другим документам (созданным им либо кем-нибуть другим). Каждая ссылка требует указания адреса URL для идентификации соответствующего объекта. Броузеры используют URL для поиска объектов Web. Когда автор указывает URL, он может использовать два типа адресов: абсолютный URL и относительный URL.

    Абсолютные URL

    Абсолютный URL содержит полный адрес объекта и протокол. Другими словами, если указана схема URL (например, http), то мы имеем дело с абсолютным URL. Вот пример такого адреса:

    http://networking.agava.ru/http/chapter6.html

    Относительные URL

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

    http://networking.agava.ru/index.html
    Если в документе HTML указан относительный URL http/chapter6.html, то броузер изменит текущий абсолютный URL на такой:

    http://networking.agava.ru/http/chapter6.html

    Подробнее об относительном URL

    Иногда при создании ссылок в документах Web может потребоваться указать на один уровень каталогов вверх. В таких случаях автор может поставить перед относительным URL две точки "..". Например, предположим, что абсолютный URL текущего документа следующий:

    http://networking.agava.ru/dir1/dir2/index.html

    Если относительный URL имеет вид ..dir3/file.html, то в результате абсолютный URL изменится:

    http://networking.agava.ru/dir1/dir3/file.html

    Далее предположим, что автор хочет добавить новый путь прямо к адресу сервера. Другими словами, он игнорирует все каталоги. В таких случаях необходимо использовать "/". Например, предположим, что абсолютный URL таков:

    http://networking.agava.ru/dir1/dir3/file.html

    Если относительный URL имеет вид /dir3/newf.html, то в результате абсолютный URL изменится:

    http://networking.agava.ru/dir3/newf.html

    Как уже обсуждалось, запрос клиента HTTP (обычно на передачу файла) является вторым этапом транзакции HTTP. Такой запрос разбивается на две категории: простой запрос и полный запрос.
    Как вы уже знаете, в версии 0.9 программы использовали только простой запрос. Сейчас используется полный запрос. Такой запрос требует, по крайней мере, строки запроса. Строка состоит из названия метода, далее слеует URI и версия протокола НТТР. Ниже мы подробнее рассмотрим три основных метода запросов НТТР.
    Методами мы называем команды НТТР. Единственным методом в протоколе 0.9 был GET, его применяли для извлечения информации. Если вы посмотрите на синтаксис строки простого запроса НТТР, то сможете легко написать программу, которая передаёт URI и символа CRLF после команды GET:
    GET <uri> CRLF Такой простой запрос означает команду серверу НТТР найти и передать объект с соответствующим URI. Объект может быть различного типа, например документ HTML, изображение, аудио- или видеофайл и др. Поскольку клиент даёт запрос на объект конкретного типа, он должен знать, как его обработать. Например, если броузер запрашивает изображение, он должен знать, как выводить его на экран. В итоге при работе только с простыми запросами сервер НТТР будет мало отличаться от обычного файл-сервера.
    Полный запрос НТТР начинаеися со строки запроса, далее следует CRLF, затем идёт информация с отдельным заголовком, в конце стоит CRLF, потом следует тело объекта.
    В разделе Поля заголовка запроса мы подробно расскажем о стилях заголовка. Тело объекта представляет собой просто данные. О формате строки запроса вы уже знаете, что она состоит из трёх частей: метод (команда) НТТР, URI, версия протокола и CRLF. Каждый из трёх элементов отделён от других пробелами (SP). Не допускается использование дополнительных символов CRLF. Формат строки запроса таков:
    Request-Line = Method SP Request URI sp HTTP-Version CRLF
    Отличие полного запроса от простого состоит в том, что в полном запросе указывается версия протокола, а также может использоваться не один метод. Далее мы опишем три основных метода НТТР - GET, HEAD и POST.
    Метод НТТР сообщает серверу, что необходимо сделать с ресурсом URI. Список методов для конкретного ресурса может изменяться динамически. Из кода статуса и строки статуса ответа сервера ваш броузер узнает о том, может ли сервер выполнять конкретные методы над данным ресурсом. Сервер Web должен вернуть код 501, если метод либо неизвестен, либо невыполним. Далее описывается набор общих методов НТТР (GET, HEAD и POST).

    Метод GET

    Метод GET протокола НТТР запрашивает сервер на предмет информации, определяемой URI. Сервер получает её, используя адрес URI из запроса клиента. Метод GET называется условным, если в заголовке запроса клиента встречается поле If-Modified-Since. В данном случае сервер передаёт клиенту информацию, если она была изменена после даты, указанной в заголовке запроса. Если клиент уже загрузил подобные данные и кэширует их, нет необходимости передавать их ещё раз. Поле If-Modified-Since мы рассмотрим в следующей главе.
    Примечание
    Наименования методов HTTP являются чувствительными к регистру. Например, GET будет правильно, а get - нет.

    Метод HEAD

    Метод HEAD почти идентичен методу GET, за исключением того, что сервер не возвращает в ответ на запрос тело объекта. Приложения используют данный метод, чтобы получить информацию о данном ресурсе, не загружая его к себе на компьютер. Такая информация (ещё её называют метаинформацией) должна быть аналогична заголовкам ответа на запрос с методом GET. Программы используют метод HEAD для проверки гипертекстовых ссылок на правильность, доступность и изменения.
    В отличие от GET для метода HEAD не существует понятия "условного". Если поле If-Modified-Since вставить в запрос HEAD, то результат не изменится (данное поле просто будет проигнорированно).

    Метод POST

    Метод POST протокола НТТР выдаёт запрос серверу Web на объект, адрес которого указан в URI из данного запроса. Другими словами, используя данный метод, клиент говорит серверу Web: "это новый ресурс и его необходимо использовать с URI, переданным мной". В большинстве случаев метод POST создаёт или записывает поверх существующей новую информацию, связанную с URI из запроса. Однако успешное завершение POST не требует появления объекта как ресурса или доступность его для будущих ссылок. Поэтому операция с методом POST может в результате не привести к появлению ресурса с заданным URI. В данном случае сервер будет возвращать код статуса в виде 200(OK) либо 204 (нет содержимого), в зависимости от того, содержит ли ответное сообщение сервера объект, указанный в запросе.
    Если клиент создаёт ресурс на текущем сервере, ему необходимо организовать код статуса 201, определяющий объект (обычно текст либо страницу HTML) и код статуса ответа сервера.
    Корректное значение поля Content Length (длина содержимого) требуется для всех запросов HTTP с методом POST. Сервер возвращает код статуса 400 (неправильный запрос), если ему не удаётся определить длину содержимого в запросе. Далее мы более подробно рассмотрим данное поле.

    Прочие методы HTTP

    Кроме методов GET, POST и HEAD протокол HTTP имеет несколько менее используемых методов: CHECKIN, CHECKOUT, DELETE, LINK, PUT,SEARCH, SHOWMETOD, SPACEJUMP, TEXTSEARCH и UNLINK. Отметим, что не все серверы полностью поддерживают все вышеперечисленные методы.
    Метод CHECKOUT похож на GET, за исключением того, что он блокирует объект от изменений его другими пользователями, метод CHEKIN, напонминающий PUT, убирает блокировку. Большинство клиентов используют GET и PUT, в отличие от CHECKOUT и CHECKIN.
    Клиенты используют метод PUT для записи файла по указанному адресу (URL). Если файл с тем же именем и расширением уже существует, то он заменяется на новый. Таким образом клиенты загружают информацию на сервер Web. Данные хранятся внутри передаваемого клиентом файла.
    Для того чтобы удалить файл с конкретным URL, клиенты используют метод DELETE. Используя метод LINK, они связывают существующий объект Web с другими объектами в сети. Для того чтобы убрать ссылку, используется метод UNLINK. В настоящее время серверы Web не воспринимают такие методы, но они зарезервированны на использование в будущем.
    Метод SHOWMETOD применяется для приёма информации о конктретном методе (методе, примененном к определённому объекту). Клиенты используют метод SPACEJUMP для обработки запроса, указанного в терминах координат в рамках объекта. Объект TEXTSEARCH применяется для запроса специфического объекта.

     

    Основные поля заголовка

    Существуют поля заголовка, использующие в запросах и ответах, но не относящиеся к коммуникационным операциям с клиентом и сервером или передаваемым данным. Среди них - основной заголовок. Он состоит из поля Date, MIME-version (обычно 1.0) и поля Pragma. Эти поля можно воспринимать как обычные переменные. Один основной заголовок может содержать несколько полей.

    Поле Date

    Данное поле представляет собой дату в формате HTTP. Например, Date: Sat, 19 Nov 1994 08:12:31 GMT.

    Поле MIME-version

    Наличие такого поля означает, что сообщение полностью удовлетворяет протоколу MIME. Для HTTP 1.0 версией MIME по умолчанию является 1.0, например: MIME-version: 1.0.

    Поле Pragma

    Поле Pragma содержит в себе "инструкции" для таких устройств, как шлюз, по всему пути следования информации. Такие "инструкции" в основном состоят из указаний на то, что "необходимо пропустить запрос". Другими словами, даже если шлюз кэширует результат запроса, он обязан просто пропустить запрос через себя к серверу и не обрабатывать его. Такая процедура обеспечивает достоверность ответа на запрос броузера. Кроме того, ваш броузер получит новую копию ресурса, если предыдущая устарела или испорчена.
    При наличии поля Pragma протокол HTTP просто определяет синтаксис запроса. Если в кэше существует копия, то она не используется. Пример поля Pragma: Pragma: no cashe.

    Поля заголовка запроса

    Поля заголовка запроса позволяют клиенту указать дополнительную информацию о запросе и о себе для сервера Web. Все поля подобного типа являются необязательными и включают в себя: Accept, Authorisation, From, If-Modofied-Since, Referer и User-Agent. Кроме того большинство серверов работают с неизвестным полем запроса как с полем заголовка объекта.
    Примечание:
    Вы можете расширить число полей заголовка, добавляя новые к данному списку, но это возможно лишь при изменении версии протокола HTTP.

    Поле Accept

    Когда клиент взаимодействует с сервером, он посылает ему поле Accept, где указывает список поддерживаемых им типов и расширений MIME. Обычно такое поле используется, если необходимо получить нестандартный тип данных. В большинстве случаев значением поля Accept является */*, что означает означает способность клинта принять и обработать любые типы и расширения MIME. Другой пример для поля Accept: Accept: text/html.
    Примечание:
    Сейчас приложения поддерживают также поля Accept-Encoding и Accept-Language, где указывается информация о кодировании или сжатии информации, а также о языке.

    Поле Authorization

    Если клиент пытается осуществить неавторизованый доступ к серверу, последний посылает ему код статуса 401 (подробнее о кодах ответов можно узнать из главы 5. Классы кодов ответов HTTP). Обычно после этого клиент использует поле Authorization заголовка запроса с тем, чтобы ответить серверу после приёма такого кода статуса. Другими словами, клиент проводит процесс регистрации на сервере. Обычно регистрация происходит один раз для каждой схемы подключения. Может случиться так, что клиенту необходимо регистрироваться несколько раз и с разными реквизитами, если он использует несколько служб одного сервера (например, HTTP и FTP). Пример: Authorization: Basic aSGWcaK23. Данная строка означает имя и пароль пользователя в формате uuencode.

    Поле From

    Данное поле используется для передачи серверу адреса электронной почты клиента с целью протоколирования работы. В таком случае сервер (или его администратор) может связаться с клиентом в случае возникновения каких-либо проблем. Поле From особенно полезно в случае, когад необходимо сообщить владельцу робота-агента о его неисправности. Пример: From: gosteve@primenet.com.

    Поле If-Modified-Since

    Клиенты используют данное поле совместно с методом GET, чтобы наложить какие-то условия на запрос. Если требуемый ресурс не был изменён после даты, указанной в этом поле, то сервер не высылает его копию. Вместо этого он вставляет код статуса 304 (нет изменений) в тело объекта. Клиенты используют метод GET с условиями, чтобы копировать только свежую информацию. Пример: If-Modified-Since: Mon, 07 May, 1996 19:43:31 GMT.

    Поле Referer

    Клиенты используют поле Referer для информирования сервера об адресе ресурса, от которого они перешли к текущему объекту. Подобная информация нужна для того, чтобы сервер мог сгенерировать список обратных ссылок, оптимизировать кэширование и многое другое. Клиент не должен заполнять это поле, если переход к данному объекту осуществляется не по ссылке (например, введён с клавиатуры). Пример: Referer: http://networking.agava.ru/index.html.

    Поле User-Agent

    Данное поле содержит информацию о клиенте в плане того, является ли он роботом, мтранником или броузером. Сервер использует данное поле в статистических целях, например, для подсчёта посещений сервера. Кроме того оно применяется для отслеживания нарушений в протоколах, автоматического распознавания броузера и для компоновки ответа с учётом ограничений броузера клиента. Хотяэто и необязательно, броузер почти всегда включает данное поле в запросы. Пример: User-Agent: Mozilla/4.0.

    http://rpm.narod.ru/protocols/http.html

    Категории: 

    Метки: