Тип 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хх: Информационная	Не используется, но зарезервирована
2xx: Успешно	Данные были успешно приняты, обработаны и использованы
3xx: Перенаправление	Для выполнения запроса требуются дополнительные действия
4xx: Ошибка клиента	Запрос содержит синтаксические ошибки либо неполон
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.

Сайт создан в системе uCoz

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

Понятие MIME

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

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