Раздел заголовков HTTP - запроса

Лабораторная работа № 3

Тема: Клиент - серверное взаимодействие в рамках

Протокола HTTP

Цель работы

Целью работы является  изучение:

- особенностей взаимодействия в модели «клиент-сервер» на примере протокола HTTP;

- структуры и синтаксиса основных частей HTTP - запроса и HTTP – ответа;

- особенностей HTTP-запроса по методам: GET и POST.

Порядок выполнения работы

Для выполнения лабораторной работы рекомендуется следующий порядок действий:

1. Изучить теоретический материал к лабораторной работе.

2. Для разработанной и размещенной на Web-сервере формы (см. лабораторную № 2) задать метод передачи данных (GET или POST).

3. Заполнить поля формы данными.

4. На основе изученного теоретического материала для заданного (в форме) метода отправки данных сформировать и сохранить в текстовом файле HTTP-запрос.

5. Сделать анализ структуры и содержимого HTTP-запроса.

6. Повторить пункты 2-5 для разных методов.

Теоретические сведения

Общая характеристика протокола HTTP

Для общения между собой клиенты и серверы WWW используют протокол передачи гипертекстовых данных (HyperText Transfer Protocol – HTTP). Данные, поступающие от клиентской части к серверной и наоборот, оформляются в виде запросов в соответствии с протоколом HTTP.

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

Аналогично, протоколы позволяют нам описать или понять процесс передачи данных, не зная на каком оборудовании этот процесс выполняется. Протокол HTTP определяет язык запросов от Web-клиента к Web-серверу.

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

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

Для большинства приложений сеанс связи открывается клиентом для каждого запроса и закрывается сервером после окончания ответа на запрос. Тем не менее, это не является особенностью протокола. И клиент, и сервер должны иметь возможность закрывать сеанс связи, например, в результате какого-нибудь действия пользователя. В любом случае, разрыв связи, инициированный любой стороной, прерывает текущий запрос, независимо от его статуса.

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

HTTP основывается на парадигме запросов/ответов.

Структура запросов клиента

Запрашивающая программа-клиент (браузер) устанавливает связь с обслуживающей программой - сервер и посылает ей запрос, который представляет собой сообщение в виде текстовых строк, которое в общем случае состоит из следующих частей:

СТРОКА ЗАПРОСА

[РАЗДЕЛ ЗАГОЛОВКОВ]

[пустая строка]

[ТЕЛО ЗАПРОСА]

Дадим общую характеристику каждой части.

Строка запроса

Синтаксис строки запроса следующий:

Метод <пробел> URL-Запроса <пробел> Версия-HTTP <конец строки>

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

Метод = "GET" | "HEAD" | "PUT" | "POST" | "DELETE" | "LINK" | "UNLINK"| дополнительный метод.

GET.Метод GET служит для получения любой информации, идентифицированной URL-Запроса. Если URL- Запроса ссылается на процесс, выдающий данные, в качестве ответа будут выступать данные, сгенерированные данным процессом, а не код самого процесса (если только это не является выходными данными процесса).

Тело запроса метода GET всегда пустое. При передаче входной информации в CGI-программы, входные данные присоединяются к URL ресурса в строке запроса (т.е. пары ключ-значение, представляющие собой введенные данные из формы, присоединяются к URL после символа "?"). Например:

GET http://stat.kar.net:88/cgi-bin/env.pl?month=Mar&day=24 HTTP/1.0

POST.Метод POST используется для запроса серверу, чтобы тот принял данные, включенные в тело запроса. По завершении обработки строки запроса и заголовков сервер передает тело запроса в программу, заданную в поле URL-Запроса.

PUT. Метод PUT запрашивает сервер о сохранении содержимого тела запроса под URL, равным URL-Запроса. Если URL-Запроса ссылается на уже существующий ресурс.

Тело-Запроса должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URL-Запроса не существует, и данный URL может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URL. Если был создан новый ресурс, сервер должен информировать направившего запрос клиента через ответ с кодом статуса "201 Created". Если существующий ресурс был модифицирован, должен быть послан ответ "200 OK", для информирования клиента об успешном завершении операции. Если ресурс с указанным URL не может быть создан или модифицирован, должно быть послано соответствующее сообщение об ошибке.

Фундаментальное различие между методами POST и PUT заключается в различном значении поля URL-Запроса. Для метода POST данный URL указывает ресурс, который будет управлять информацией, содержащейся в теле запроса, как неким придатком. Ресурс может быть обрабатывающим данные процессом, шлюзом в какой-нибудь другой протокол, или отдельным ресурсом, допускающим аннотации. В противоположность этому, URL для запроса PUT идентифицирует информацию, содержащуюся в теле запроса. Использующий запрос PUT точно знает какой URL он собирается использовать, и получатель запроса не должен пытаться применить этот запрос к какому-нибудь другому ресурсу.

DELETE. Метод DELETE используется для удаления ресурсов, идентифицированных с помощью URI-Запроса. Результаты работы данного метода на сервере могут быть изменены с помощью человеческого вмешательства (или каким-нибудь другим способом). В принципе, клиент никогда не может быть уверен, что операция удаления была выполнена, даже если код статуса, переданный сервером, информирует об успешном выполнении действия. Тем не менее, сервер не должен информировать об успехе до тех пор, пока на момент ответа он не будет собираться стереть данный ресурс или переместить его в некоторую недостижимую область.

LINK. Метод LINK устанавливает взаимосвязи между существующим ресурсом, указанным в URI-Запроса, и другими существующими ресурсами. Отличие метода LINK от остальных методов, допускающих установление ссылок между документами, заключается в том, что метод LINK не позволяет передавать в запросе Тело-Запроса, и в том, что в результате работы данного метода не создаются новые ресурсы.

UNLINK. Метод UNLINK удаляет одну или более ссылочных взаимосвязей для ресурса, указанного в URI- Запроса. Эти взаимосвязи могут быть установлены с помощью метода LINK или какого-нибудь другого метода, поддерживающего заголовок "Link". Удаление ссылки на ресурс не означает, что ресурс прекращает существование или становится недоступным для будущих ссылок.

Раздел заголовков HTTP - запроса

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

Например:

Host: www.ora.com

Перечень HTTP заголовков достаточно широк, рассмотрим некоторые из них.

From. В случае присутствия поля From, оно должно содержать полный E-mail адрес пользователя, который управляет программой-агентом, осуществляющей запросы. Этот адрес должен быть задан в формате, определенном в RFC 822. Пример формата данного заголовка следующий:

From: webmaster@WWW.org

Данное поле может быть использовано для функций захода в систему, а также для идентификации источника некорректных или нежелательных запросов. Оно не должно использоваться, как несекретная форма разграничения прав доступа. Интерпретация этого поля состоит в том, что обрабатываемый запрос производится от имени данного пользователя, который принимает ответственность за применяемый метод. В частности, агенты-роботы должны использовать этот заголовок для того, чтобы можно было связаться с тем человеком, который отвечает за работу робота, в случае возникновения проблем. Почтовый Internet адрес, указывающийся в этом поле, не обязан соответствовать адресу того хоста, с которого был послан данный запрос. По возможности, адрес должен быть доступным Internet адресом вне зависимости от того, является ли он в действительности Internet E-mail адресом или Internet E-mail представлением адреса других почтовых систем.

Замечание: Клиент не должен использовать поле заголовка From без позволения пользователя, так как это может войти в конфликт с его частными интересами или с местной, используемой им, системой безопасности. Настоятельно рекомендуется предоставление пользователю возможности запретить, разрешить или модифицировать это поле в любой момент перед запросом.

If-Modified-Since. Поле заголовка If-Modified-Since используется с методом GET для того, чтобы сделать его условным: если запрашиваемый ресурс не изменялся во времени, указанного в этом поле, копия этого ресурса не будет возвращена сервером; вместо этого, будет возвращен ответ "304 Not Modified" без тела ответа.

Пример использования заголовка:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

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

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

Пример:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

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

Заголовок User-Agent может использоваться с целью определения количества браузеров того или иного типа, обратившихся к ресурсу, так как заголовок определяет тип браузера (название), который осуществляет запрос.

Пример:

User-Agent: Mozilla/2.02 Cold (WinNT;I)

Accept. Заголовок задает media-тип, которые предпочитает принимать клиент, если представлены несколько типов, они отделяются символом ",".

Пример:

Accept: image/gif, image/x-xbitmap, image/jpeg, */*

Host. Заголовок задает имя хоста и номер порта URL в виде

хост_имя[:порт].

Пример:

Host: sst.uar.net:88

Content-Type. Заголовок определяет тип кодирования (media-тип/подтип) передаваемых в составе запроса полезных данных. Например:

application/x-www-form-urlencoded

Пример:

Content-Type: application/x-www-form-urlencoded

Content-Еncoding. Заголовок задает возможность кодирования, используемое для передачи содержимого тела. Возможные значения: gzip, compress. Допускается задание нескольких схем кодирования, разделенных запятой и расположенных в том порядке, в котором применялись к исходным данным.

Content-Length. Заголовок задает объем данных(в байтах) в переданном теле содержимого. Для запросов, имеющих динамический характер, размер содержимого точно указать нельзя. В этом случае этот заголовок опускается.

Пример:

Content-Length: 20

Connection. Заголовок задает опции, желательные для данного соединения, но не для последующих соединений.

Пример:

Connection: Keep-Alive

Тело HTTP - запроса

Представляет собой дополнительные данные, посылаемые серверу. Тело сообщения включается в запрос, только если метод запроса подразумевает его наличие. Для спецификации HTTP/1.0 такими методами являются POST и PUT. В общем случае, на присутствие тела сообщения указывает присутствие таких заголовков, как например, Content-Length, в передаваемом запросе.

Примеры HTTP-запросов

Пример запроса по методу GET:

GET http://193.172.33.2/users/info.htm  HTTP /1.0

Connection: keep-alive

User-Agent: Mozilla/2.02 Cold (Win NT; I)

Accept: image /gif, image/x-x bitmap, image/jpeg, *.*

- необходимо получить ресурс (info.htm) расположенный на сервере по указанному адресу (http://193.172.33.2/users/).

Пример запроса по методу HEAD:

HEAD http://www.ora.com/common.htm HTTP/1.0

Connection: keep-alive

User-Agent: Netscape Navigator/3.0

Accept: image /gif, image/x-x bitmap, image/jpeg, *.*

- аналогичен методу GET, только в ответ на запрос метода HEAD сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию о ресурсе http://www.ora.com/common.htm .

Пример запроса по методу POST: позволяет послать на сервер данные в теле запроса

POST http://www.mmm.kiev.ua/env.pl HTTP/1.0

User-Agent: Mozilla/2.02 Cold (Win NT; I)

Accept: image /gif, image/x-x bitmap, image/jpeg, *.*

Content-type: application/x-www-form-urlencoded

Content-Length: 20

Month=sep&date=24

- сервер передает тело содержимого (Month=sep&date=24) в программу, заданную URL (http://www.mmm.kiev.ua/env.pl).

Структура ответов сервера

Каждый ответ сервера на запрос клиента состоит из следующих частей:

СТРОКА СОСТОЯНИЯ

[БЛОК ЗАГОЛОВКОВ]

[пустая строка]

[ТЕЛО РЕСУРСА (затребованных данных)]

Пример:

HTTP/1.0 200 Document follows

Date: Fri, 20 Sep 2005 08:17:58 GMT

Server: NCSA/1.5.2

Last-modified: Mon, 17 Jun 2005 21:53:08 GMT

Content-type: text/html

Content-Length: 2482

(Тело документа)

Строка состояния

Синтаксис cтроки состояния

Версия HTTP <SP> код состояния <SP> фраза-описание <CRLF>

СТРОКА СОСТОЯНИЯ является Строкой-Статус и содержит:

- версию HTTP, которой данный сервер пользуется для передачи ответа;

- цифровой код состояния или статуса ответа на запрос;

- ассоциированное со статусом (кодом состояния) фраза-объяснение.

Все элементы строки разделены пробелами. Не разрешены символы <CR> и <LF>, за исключением завершающей последовательности <CRLF>.

Код состояния: это трехзначное число, обозначающие результат обработки сервером запроса клиента.

Строка описание: представляет собой текст, фразу-объяснение кода состояния.