Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
14
Лекция 1.Протокол HTTP
В середине 90-х годов очень популярной стала WWW (World Wide Web) — «Всемирная паутина». Это набор протоколов и программ для Интернета, представляющих информацию в гипертекстовом формате. Знаменитый браузер Mosaic, созданный в Национальном центре по применению супер-ЭВМ (National Center for Supercomputer Applications, NCSA), был первым графическим Web-браузером и способствовал популяризации WWW. Web разработана в 1989 году в Европейской лаборатории физики частиц (European Laboratory for Particle Physics, CERN) Тимоти Бернерсом-Ли (Timothy Berners-Lee). В настоящее время всеми стандартами, имеющими отношение к Web, ведает Консорциум World Wide Web (W3C).
Гипертекст применяется для создания документов, взаимосвязанных ссылками, — с ними легко управляться даже новичкам. В протоколах для Web в одних из первых в Интернете стали использовать гипертекст. Для упрощения и повышения эффективности работы с большими объемами непоследовательной информации. Теперь пользователю не обязательно заучивать команды базового протокола FTP, а для получения информации из Интернета не надо быть асом-программистом — достаточно просто щелкнуть ссылку на странице.
Для упаковки и передачи данных в Web применяются протоколы MIME (Multipurpose Internet Mail Extensions) и TCP/IP (Transmission Control Protocol/Internet Protocol), а также и другие, например FTP и Telnet. Специально для Web разработаны указатели URL (Uniform Resource Locator), протокол HTTP (Hypertext transfer Protocol), язык HTML (Hyper-text Markup Language) и интерфейс CGI (Common Gateway Interface).
Унифицированные указатели ресурсов (URL)
Указатель URL (Uniform Resource Locator) — это адрес сетевого ресурса. Он похож на имя файла, но дополнительно содержит имя сервера и информацию о сетевом протоколе, используемом данным ресурсом. В некоторых случаях URL включает сведения об имени пользователя, а также специальные аргументы и параметры протокола.
На Web-страницах URL используются для ссылок на другие страницы. В виде URL можно описать многие распространенные сетевые команды, указатели на файлы (доступные через FTP) и на сообщения из групп новостей Usenet (всемирной сети UNIX-систем, функционирующей как электронная доска объявлений для групп пользователей) и т.д.
Все это было доступно и раньше, но появление URL значительно упростило программы, представляющие ценную информацию в гипертекстовой среде. Действительно до эры URL процесс передачи всей информации о сервере, файле, протоколе, пользователе и аргументах был достаточно неудобен, особенно для новичков. С появлением URL значительно упростился весь механизм.
Указатель URL состоит из следующих частей:
<схема>:<специальное_имя>
где <схема> — это название схемы (используемый протокол, например http, ftp и т. д.), а <специальное_имя> — имя в формате, зависящем от используемой схемы.
Многие URL имеют следующий формат:
<протокол>://<пользователь>:<пароль>@<хост>:<порт>/<путь>
где
Для Web-страницы URL выглядит, например, так:
http: //www.fictionalcorp.com/corpinfo/sales.html
Ниже перечислены некоторые популярные схемы:
Более короткий URL — http://www.fictionalcorp.com — указывает на "основную страницу» этого сервера. Если явно не задано имя файла, то HTTP-серверы используют значение по умолчанию (часто это default.html или index.html). Приведенный URL можно преобразовать к более явному виду: http://www.fictiorialcorp.com/default.html.
Для протокола FTP применяется сходный синтаксис. Обращение к файлу bar.txt подкаталога /foo FТР-сервера ftp.fictionalcorp.com на языке URL выглядит следующим образом:
ftp://ftp.fictionalcorp.com/foo/bar.txt
Из-за огромной популярности World Wide Web в Интернете многие браузеры предполагают наличие префикса «http://» в URL, не содержащем явного указания протокола. Обычно имена доменов в явном виде содержат информацию о протоколе. Например, FТР-сервер компании называется ftp.fictionalcorp.com, а ее HTTP-сервер— www.fictionalcorp.com. Однако с появлением URL компания вправе использовать одно и то же имя fictionalcorp.com для обоих серверов. Тогда при использовании их ресурсов необходимо явно задавать соответствующий протокол, например ftp://fictionalcorp.com/public/foo.txt или http://fictionalcorp.com/
Частичный или относительный URL — тот, в котором не указан протокол, хост, порт или путь, а лишь относительное имя ресурса. Например, если Web-страница http://www.fictionalcorp.com/piiblic/foo/bar.html ссылается на bletch.html, это не что иное, как относительная форма от http://www.fictionalcorp. com/public/foo/bletch.html.
Как уже говорилось ранее, синтаксис URL меняется в зависимости от URL-схемы. Например, в протоколе HTTP символ «#» после имени HTML-файла обозначает точку привязки (закладку). Так, http://www.fic-tionafcorp.com/foo.html#disclaimer указывает на фрагмент disclaimer документа foo.html.
Вместо подкаталога и имени файла URL может содержать другую информацию о ресурсе. Так выгладит URL для протокола NNTP:
nntp://<хост>:<порт>/<группа_новостей>/<статья>
где <группа_новостей> — имя группы новостей, а <статья> — номер статьи.
Вообще говоря, в URL следует использовать только алфавитно-цифровые символы, так как большинство специальных символов зарезервированы или их прямое использование небезопасно. К первым относятся: «;», «/», «?», «:», «@», «=», «&». Ненадежные символы - «<», «>», «»»,«#», «%», «{», «}», «|», «\», « », «-», «[», «]», «'».
Если имя ресурса содержит зарезервированный символ или символ, не принадлежащий US-ASCII, то перед использованием в URL имя надо закодировать. При кодировании символ заменяется тремя новыми - знаком процента (%) и двумя шестнадцатеричными цифрами, представляющими код заменяемого символа.
Предпосылки
Протокол HTTP — основной и достаточно простой способ передачи данных между Web-сервером и клиентом. До появления Web и HTTP для передачи файлов в Интернете в качестве протокола ввода/вывода чаще всего применяли FTP.
HTTP — это компактный, быстрый протокол ввода/вывода, работающий с URL и предназначенный для сред гипертекст/гипермедиа. В отличие от FTP, это протокол без состояний и имеет лишь несколько команд (методов). Благодаря использованию MIME, HTTP приспосабливается ко многим форматам данных и различным задачам ввода/вывода.
HTTP — клиент-серверный протокол, реализующий модель запрос/ответ. HTTP-клиент, или пользовательский агент (обычно это Web-браузер), подключается к HTTP-серверу с помощью URL и запрашивает ресурс, например HTML-документ.
Для инкапсуляции данных в этой модели применяются расширения MIME. Структура данных, пересылаемых между клиентом и сервером, напоминает электронную почту. Она состоит из тела сообщения и метаданных (заголовков сообщений). Протокол HTTP передает информацию в формате MIME. Метаданные содержат информацию, необходимую для передачи данных между HTTP-сервером и клиентом. Однако HTTP допускает двоичный формат, чего обычный MIME (из-за 7-битных ограничений почтовых шлюзов) не позволяет.
В сеансе связи, как правило, участвуют HTTP-клиенты (Web-браузеры) и HTTP-серверы (Web-серверы) и реже — прокси-серверы. Последние уступают в качестве сервера по отношению к клиенту и в качестве клиента по отношению к другому серверу, передавая исходный запрос клиента через шлюз (например, межсетевой экран между интрасетью компании и Интернетом).
Традиционно HTTP-клиенты и серверы общаются через 80-й порт TCP/IP, по умолчанию зарезервированный для HTTP. Однако могут использоваться и другие порты, явно указанные в URL. В дополнение замечу, что HTTP не предполагает применение именно TCP/IP и отлично функционирует с другими протоколами гарантированной доставки.
Web-браузер часто обрабатывает Web-страницы, состоящие из многих объектов, например, самого HTML-документа и нескольких изображений (GIF, JPEG, PNG и др.). Большинство HTTP-клиентов для чтения начального HTML-документа создают только один поток (с одним подключением к серверу), а затем еще несколько потоков (каждый с отдельным подключением к серверу) для получения остальных необходимых файлов. Соединение устанавливается по запросу клиента и разрывается после ответа сервера.
Все HTTP-транзакции имеют один общий формат. Каждый запрос клиента и ответ сервера состоит из трех частей: строки запроса (ответа), раздела заголовка и тела. Клиент инициирует транзакцию следующим образом:
1. Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию - 80). Затем клиент посылает запрос документа, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например, в запросе
GET /index.html HTTP/1.0
используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html. Методы HTTP более подробно рассматриваются ниже.
2. Клиент посылает информацию заголовка (необязательную), чтобы сообщить серверу информацию о своей конфигурации и данные о форматах документов, которые он может принимать. Вся информация заголовка указывается построчно, при этом в каждой строке приводится имя и значение. Например, приведенный ниже заголовок, посланный клиентом, содержит его имя и номер версии, а также информацию о некоторых предпочтительных для клиента типах документов:
User-Agent: Mozilla/4.05 (WinNT; 1)
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Завершается заголовок пустой строкой.
3. Послав запрос и заголовки, клиент может отправить и дополнительные данные. Эти данные используются главным образом теми CGI-программами, которые применяют метод POST. Клиенты (например, Netscape Navigator-Gold), также могут использовать их для помещения отредактированной страницы обратно на Web-сервер.
Сервер отвечает на запрос клиента следующим образом:
1. Первая часть ответа сервера - строка состояния, содержащая три поля: версию HTTP, код состояния и его описание. Поле версии содержит номер версии HTTP, которой данный сервер пользуется для передачи ответа.
Код состояния - это трехразрядное число, обозначающее результат обработки сервером запроса клиента. Описание, следующее за кодом состояния, представляет собой просто понятный для человека текст, поясняющий код состояния. Например, строка состояния
НТТР/1.0 200 OK
говорит о том, что сервер для ответа использует версию HTTP 1.0. Код состояния 200 означает, что запрос клиента был успешным, и затребованные данные будут переданы после заголовков.
2. После строки состояния сервер передает клиенту информацию заголовка, содержащую данные о самом сервере и затребованном документе. Ниже приведен пример заголовка:
Date: Fri, 10 Jan 1998 08:17:58 GMT
Server: Apache/1.2.6
Last-modified: Mon, 12 Jun 1997 21:53:08 GMT
Content-type: text/html
Content-length: 2482
Завершает заголовок пустая строка.
3. Если запрос клиента успешен, то посылаются затребованные данные. Это может быть копия файла или результат выполнения CGI-программы. Если запрос клиента удовлетворить нельзя, передаются дополнительные данные в виде понятного для пользователя разъяснения причин, по которым сервер не смог выполнить данный запрос.
В HTTP 1.0 за передачей сервером затребованных данных следует разъединение с клиентом, и транзакция считается завершенной, если не передан заголовок Connection: Keep Alive. В HTTP 1.1 сервер по умолчанию не разрывает соединение, и клиент может посылать другие запросы. Поскольку во многие документы встроены другие документы - изображения, кадры, апплеты и т.д., это позволяет сэкономить время и затраты клиента, которому в противном случае пришлось бы для получения всего одной страницы многократно соединяться с одним и тем же сервером. Таким образом, в HTTP 1.1 транзакция может циклически повторяться, пока клиент или сервер не закроет соединение явно.
HTTP не сохраняет информацию по транзакциям, поэтому в следующей транзакции приходится начинать все заново. Преимущество такого правила организации взаимодействия состоит в том, что HTTP сервер может обслужить в заданный промежуток времени гораздо больше клиентов, ибо устраняются дополнительные расходы на отслеживание сеансов от одного соединения к другому. Есть и недостаток: для сохранения информации по транзакциям более сложные CGI-программы должны пользоваться скрытыми полями ввода или внешними средствами, например "ключиками" (cookies) Netscape.
Запросы клиента разбиваются на три раздела. Первая строка сообщения всегда содержит HTTP-команду, называемую методом URI, который обозначает запрашиваемый клиентом файл или ресурс, и номер версии HTTP. Следующие строки запроса клиента содержат информацию заголовка. Информация заголовка содержит сведения о клиенте и информационном объекте, который он посылает серверу. Третья часть клиентского запроса представляет собой тело содержимого - собственно данные, посылаемые серверу.
URI (Uniform Resource Identifier, универсальный идентификатор ресурса) - это общий термин для всех допустимых форматов схем адресации, поддерживаемых в World Wide Web. Сейчас общепринятой является схема адресации с использованием универсальных локаторов ресурсов (URL).
Методы
Метод - это HTTP-команда, с которой начинается первая строка запроса клиента. Метод сообщает серверу о цели запроса. Для HTTP определены три основных метода: GET, HEAD и POST. Определены и другие методы, но они не так широко поддерживаются серверами, как три перечисленных (хотя эти другие методы в будущем будут использоваться более часто). При задании имен методов учитывается регистр, поэтому GET и get различаются.
Метод GET
GET - это запрос информации, расположенной на сервере по указанному URL. GET - наиболее распространенный метод поиска с помощью браузеров документов для визуализации. Результат запроса GET может представлять собой, например файл, доступный для сервера, результат выполнения программы или CGI-сценария, выходную информацию аппаратного устройства и т.д.
Если клиент использует в своем запросе метод GET, сервер отвечает строкой состояния, заголовками и затребованными данными. Если сервер не может обработать запрос вследствие ошибки или отсутствия полномочий, он, как правило, посылает в информационном разделе ответа текстовое пояснение.
Тело информационного содержимого запроса GET всегда пустое. GET в переводе на человеческий язык означает примерно следующее: "Дайте мне этот файл". Для идентификации указанного в запросе клиента файла или программы обычно используется полное имя этого объекта на сервере.
Ниже приведен пример успешного запроса GET на получение файла. Клиент посылает запрос:
GET /index.html HTTP/1.О
Connection: Keep-Alive
User-Agent: Mozilla/4.05 (WinNT; 1)
Host: www.ora.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Сервер отвечает:
HTTP/1.0 200 Document follows
Date: Fri, 20 Jan 1998 08:17:58 GMT
Server: Apache/1.2.6
Last-modified: Mon, 20 Jun 1997 21:53:08 GMT
Content-type: text/html
Content-length: 2482
(далее следует тело документа)
Метод GET используется также для передачи входной информации в CGI-программы посредством тегов форм. Поскольку тело запроса GET пусто, входные данные присоединяются к URL в строке GET запроса. Если в теге <form> задано значение атрибута method="GET", то пары ключ-значение, представляющие собой введенные из формы данные, присоединяются к URL после вопросительного знака. Пары отделяются друг от друга амперсандом (&). Например, по запросу
GET /cgi-bin/birthday.pl?month=august&date=24 HTTP/1.О
сервер передаст в CGI-программу birthday.pl значения month и date, указанные в форме, созданной на клиенте. Входные данные в конце URL кодируются в соответствии со спецификацией CGI. Чтобы специальные символы интерпретировались обычным образом, используются их шестнадцатеричные коды.
Аналогичным образом в методе GET может передаваться информация о дополнительных путях. При этом дополнительный путь указывается после URL, т.е. /cgi-bin/display.pl/cgi/cgi_doc.txt. Сервер определяет, где заканчивается имя программы (display.pl). Все данные, которые следуют за именем программы, интерпретируются как дополнительный путь.
Метод HEAD
Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Информация заголовка запроса HEAD должна быть такой же, как в запросе GET.
Этот метод используется, когда клиент хочет найти информацию о документе, не получая его. Для метода HEAD существует множество приложений. Например, клиент может затребовать следующую информацию:
Следует отметить, что большая часть информации заголовка, которую посылает сервер, не является обязательной и может предоставляться не всеми серверами. Рекомендуемый вариант для Web-клиентов - учитывать гибкость ответов сервера и предусматривать определенные меры по умолчанию, если сервер не передал необходимую информацию заголовка.
Ниже приведен пример HTTP-транзакции с использованием запроса HEAD. Клиент посылает запрос:
HEAD /index.html HTTP/1.0
Connection: Close
User-Agent: Mozilla/4.05 (WinNT; 1)
Host: www.ora.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Сервер отвечает:
HTTP/1.0 200 Document follows
Date: Fri, 20 Jan 1998 08:17:58 GMT
Server: Apache/1.2.6
Last-modified: Mon, 17 Jun 1996 21:53:08 GMT
Content-type: text/html
Content-length: 2482
(Тело содержимого в ответе на запрос HEAD не передается.)
Метод POST
Метод POST позволяет посылать на сервер данные в запросе клиента. Эти данные направляются в программу обработки данных, к которой сервер имеет доступ (например, в CGI-сценарий). Метод POST может использоваться во многих приложениях. Например, его можно применять для передачи входных данных для:
Данные, посылаемые на сервер, находятся в теле содержимого запроса клиента. По завершении обработки запроса POST и заголовков сервер передает тело содержимого в программу, заданную URL. В качестве схемы кодирования с методом POST используется URL-кодирование, которое позволяет преобразовывать данные форм в список переменных и значений для CGI-обработки.
Ниже приведен небольшой пример запроса клиента с использованием метода POST. Клиент посылает на сервер данные о дне рождения, введенные в форму:
POST /cgi-bin/birthday.pl HTTP/1.0
User-Agent; Mozilla/4.05 (WinNT; 1)
Accept: image/gif, iinage/x-xbj.tmap, image/jpeg, J.mage/pjpeg, */*
Host: www.ora.com
Content-type: application/x-www-form-urlencoded
Content-Length: 20
month=august&date=24
Другие методы
Приведенные ниже методы также определены, хотя и используются не столь часто:
LINK связывает информацию заголовка с документом на сервере.
UNLINK отменяет связь информации заголовка с документом на сервере.
PUT помещает тело содержимого запроса по указанному URI.
DELETE удаляет данные, находящиеся на сервере по заданному URI.
OPTIONS запрашивает информацию о коммуникационных параметрах сервера. Чтобы запросить данные обо всем сервере в целом, вместо URI запроса следует использовать символ *.
TRACE требует, чтобы тело содержимого запроса было возвращено без изменений. Используется для отладки.
Ответ сервера на запрос клиента состоит из трех частей. Первая строка - это строка ответа сервера, которая содержит номер версии HTTP, число, обозначающее состояние запроса, и краткое описание состояния. После строки ответа следует информация заголовка и тело содержимого, если таковое имеется.
Коды состояния
Протокол HTTP определяет набор кодов состояния, которые должны быть понятны и клиенту и серверу, чтобы те могли успешно передавать сообщения. Коды разбиты на категории, перечисленные в ниже.
|
Информационные |
100 - 199 |
Сообщения конкретных приложений |
|
Успешные |
200 - 299 |
Запрос успешно обработан |
|
Перенаправление |
300 - 399 |
Для обработки запроса требуются дополнительные действия клиента. Обычно они выполняются без участия пользователя |
|
Ошибка клиента |
400 - 499 |
Проблемы на стороне клиента |
|
Ошибка сервера |
500 - 599 |
Проблемы на стороне сервера |
Каждый код состояния HTTP представляет собой число, после которого следует текстовая строка, содержащая дополнительную метаинформацию. В таблице приведены коды состояния и их описания. Помимо кодов состояния, включенных в спецификации HTTP, приложения способны определять свои коды состояния.
|
200 |
OK |
Нет ошибки, запрос успешно обработан |
|
201 |
Created |
Выполнена команда POST |
|
202 |
Accepted |
Получен асинхронный запрос: он уже получен, но не обязательно обработан |
|
204 |
No Content |
Запрос успешно обработан, но клиенту нечего отобразить. Это иногда полезно в качестве метаинформации для ответов, которые не нужно показывать пользователю |
|
300 |
Multiple Choices |
Требуемый ресурс доступен из многих мест. В ответе возвращается список альтернатив. Предпочтительный выбор сервера включен в поле Location ответа. |
|
301 |
Moved Permanently |
Требуемый URL перемещен на новый URL (указанный в поле Location ответа). Все последующие ссылки на этот ресурс должны использовать новый URL. |
|
302 |
Moved Temporarily |
Требуемый URL временно перемещен на новый URL (указанный в поле Location ответа). Последующие ссылки на этот ресурс должны использовать старый URL |
|
304 |
Not Modified |
Выполнена команда «условный GET», однако, документ не изменялся со времени, указанного в поле If-Modified-Since |
|
400 |
Bad Request |
Запрос не распознан. Клиенту следует послать исправленный запрос |
|
401 |
Unauthorized |
Если запрос был анонимным, то его следует аутентифицировать. Если запрос был аутентифицирован, то это — отказ в доступе |
|
403 |
Forbidden |
Сервер отказывается обработать запрос. Обычная причина — нарушение прав доступа |
|
404 |
Not found |
Сервер не нашел указанный URL |
|
500 |
Internal Server Error |
Произошла непредвиденная ошибка сервера |
|
501 |
Not Implemented |
Сервер не поддерживает этот запрос |
|
502 |
Bad Gateway |
Прокси-сервер (или шлюз) получил неправильный ответ от сервера, к которому он подсоединен |
|
503 |
Service Unavailable |
Сервер временно недоступен или отказывается обработать запрос. Обычная причина — перегрузка сервера или его обслуживание. |
Поля заголовка
Заголовки HTTP-сообщений имеют различные поля, используемые в запросах и ответах. Одни из них специально предназначены для запросов клиента, другие — для ответов сервера. Некоторые из этих полей не поддерживаются определенными клиентами или серверами. Подробнее поля описаны ниже.
Accept
В поле Accept перечислены возможные форматы данных при ответе на запрос. Большинство клиентов показывают допустимость всех форматов, водя в это поле звездочку (*). Нераспознанные форматы данных передаются пользователю с просьбой сопоставить их с некоторым MIME-типом.
Accept-Charset
Здесь перечислены наборы символов (помимо US-ASCII и ISO-8859-1), поддерживаемые клиентом.
Accept-Encoding
Это поле сходно с полем Accept, но описывает допустимые кодировки содержимого ответа.
Accept-Language
Это поле сходно с полем Accept, но указывает языки, допустимые в ответе.
Allow
В поле Allow перечислены поддерживаемые сервером команды (GET, HEAD и т. д.). Клиенту разрешено их использовать.
Authorization
Его применяют НТТР-серверы, не разрешающие анонимный доступ к некоторым ресурсам. В этом поле запроса передается «удостоверение личности» пользователя.
Для случаев, когда анонимный доступ невозможен, HTTP предоставляет простой механизм аутентификации типа «запрос-ответ». Допустимы различные механизмы аутентификации. В базовом для HTTP механизме аутентификации имя пользователя и пароль шифруются нестойким MIME-кодированием Base64. Некоторые HTTP-клиенты и серверы поддерживают другие, более безопасные методы.
В заголовок ответа, содержащего код «401 Unauthorized», сервер обязательно включает поле WWW-Authenticate, где описана причина отказа и поддерживаемые сервером методы аутентификации. После этого пользователь повторно передает запрос, заголовок которого содержит дополнительное поле Authorization с «удостоверением личности» для указанного механизма аутентификации. Если сервер не принимает это «удостоверение личности», то он отвечает кодом «403 Forbidden».
Content-Encoding
Здесь указан механизм кодирования (zip, compress и т. д.), который следует использовать для декодирования данных.
Content-Language
Здесь указан естественный язык предполагаемой аудитории.
Content-Length
Здесь определен размер тела переданного сообщения. В случае команды HEAD в этом поле указан размер данных, который имел бы место при использовании команды GET.
Content-Type
Здесь определен тип тела переданного сообщения. Для HTML-документов в этом поле обыкновенно находится «text/html». В случае команды HEAD в этом поле указан тип данных, который бы имел место при использовании команды GET.
Date
Здесь указаны дата и время создания сообщения.
Expires
Здесь указаны дата и время, когда данные теряют актуальность. После наступления указанного момента и до обновления данных HTTP-клиенты не должны эти данные кэшировать. Если в этом поле записан 0 (хотя это и неестественный вид), то данные теряют актуальность немедленно.
From
Здесь указан адрес электронной почты запрашивающего пользователя. Это поле применяется не в целях аутентификации, а для регистрации пользователей. В случае возникновения ошибок автоматизированные HTTP-клиенты, например роботы, должны содержать адрес электронной почты лица, ответственного за запуск робота.
If-Modified-Since
Это поле даты и времени используется командой GET для доступа к ресурсу только в том случае, если он был изменен. Это поле полезно для клиентов, применяющих кэширование. Если изменений нет, то возвращается код состояния «304 Not Modified».
Last-Modified
Здесь указана дата последнего изменения данных.
Link
Это поле позволяет устанавливать взаимосвязь данных с другим ресурсом, иерархической структурой или путями просмотра.
Location
В этом поле содержится точный URL прежнего местонахождения ресурса для случаев автоматического перенаправления (коды состояния 300-399).
MIME-Version
Содержит номер версии используемого протокола MIME.
Pragma
Это многоцелевое поле для директив конкретной реализации. Одной из распространенных директив является «no-cache», показывающая что данные не следует кэшировать.
Refer
Позволяет клиенту определять URL, от которого получен запрашиваемый URL. Это помогает выявлять обратные ссылки, позволяющие отслеживать ошибки и определять доходы от рекламы. Обратные ссылки иногда содержат конфиденциальную информацию, поэтому пользователи должны иметь возможность отключать это поле. К сожалению, большинство распространенных в настоящее время HTTP-клиентов не позволяют этого сделать.
Retry-After
Указывает интервал времени, в течение которого службы недоступны. Используется совместно с кодом состояния «503 Service Unavailable».
Server
Поле указывает название и версию HTTP-сервера.
Title
Поле указывает описательное имя объекта.
URI
Здесь перечислены некоторые или все унифицированные идентификаторы ресурсов URI (Uniform Resource Identifier), доступные для данного ресурса.
User-Agent
Поле указывает название и версию HTTP-клиента.
WWW-Authenticate
Реализует неанонимный доступ с аутентификацией типа «запрос/ответ». В этой схеме «удостоверение личности» не шифруется. Подробности — ранее в разделе «Authorization».
Указание (MIME) media-типа используется для передачи сведений о формате содержимого в HTTP-транзакциях. Клиенты используют MIME-типы в своих заголовках Accept для того, чтобы сообщить, в каких форматах они предпочитают принимать данные. Серверы используют MIME-типы в заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое: то ли это HTML, который нужно форматировать, то ли это GIF или JPEG, требующий визуализации, то ли это данные в формате PDF, для которого нужно открывать внешнюю программу просмотра или использовать дополнительное приложение.
MIME (Multipurpose Internet Mail Extension) — многоцелевые расширения электронной почты для Internet), разработанные для обеспечения возможности передачи присоединенных данных по Internet средствами электронной почты. Из почтовых протоколов, в силу своей простоты и наглядности, расширения MIME перекочевали в HTTP. MIME-тип указывается в формате тип/подтип. Символ * используется как метасимвол; например, следующий заголовок клиента означает, что принимаются документы во всех форматах:
Accept: •"•/*
Следующий заголовок клиента означает, что принимаются все типы формата text независимо от подтипа:
Accept: text/*
Серверы и CGI-программы должны проверять данные о принимаемых типах, содержащиеся в заголовке Accept, и по возможности выдавать данные соответствующего типа. Большинство серверов определяют формат документа по суффиксу имени файла. Например, файлы с расширениями .htm и .html — это файлы в формате HTML, поэтому сервер посылает такой документ с типом text/html в заголовке Content-Type. При вызове CGI-программы серверу неизвестен формат возвращаемых данных, поэтому программа должна сообщить тип содержимого. По этой причине каждая CGI-программа должна включать в результат своей работы заголовок Content-Type, например:
Content-Type: text/html
В следующей таблице перечислены общепринятые MIME-типы, а также суффиксы имен файлов, распознаваемые большинством серверов. Большинство серверов можно легко настроить так, чтобы они распознавали и другие суффиксы.
|
Тип/Подтип |
Обычное расширение |
|
application/* |
Используется для обозначения принадлежности данных какому-либо приложению. При этом application/octet-stream обычно используется для обозначения бинарных данных неизвестного типа. |
|
application/msword |
doc |
|
application/octet-stream |
bin |
|
application/pdf |
|
|
application/postscript |
ai, eps, ps |
|
application/rtf |
rtf |
|
application/sgml |
sgml |
|
application/x-tex |
tex |
|
application/zip |
zip |
|
application/x-wav |
wav |
|
image/* |
Изображения различного типа |
|
image/gif |
gif |
|
image/jpeg |
jpeg, jpg, jpe |
|
image/tiff |
tiff, tif |
|
multipart/* |
Используется для составных документов, т.е. документов содержащих в себе несколько частей, являющихся документами разного типа. Например, это могут быть почтовые сообщения, содержащие текст письма и набор прикрепленных файлов. |
|
multipart/alternative |
|
|
multipart/digest |
|
|
multipart/form-data |
|
|
multipart/header-set |
|
|
multipart/mixed |
|
|
text/* |
Текстовые данные с/без разметки |
|
text/html |
html, htm |
|
text/plain |
txt, rtx |
|
video/* |
видеопоток |
|
video/mpeg |
mpeg, mpg |
В настоящее время используется версия 1.1 протокола HTTP. Ее поддерживают все основные клиенты (браузеры) и Web-серверы. Протокол HTTP 1.1 описан в RFC 2068 и превосходит предыдущую версию — HTTP 1.0, — прежде всего, по производительности.
Однако есть и другие отличия, некоторые из них описаны ниже.