Санкт-петербургский государственный политехнический


HTTP запрос имеет следующий формат



бет2/6
Дата15.07.2016
өлшемі454 Kb.
#201097
түріУчебное пособие
1   2   3   4   5   6

HTTP запрос имеет следующий формат


Начальная строка

Заголовки запроса

Тело-Запроса

Начальная строка в запросе называется строкой запроса (Request-Line) и имеет формат или <Метод><Версия>.



Метод обозначает действие, которое следует применить к запрашиваемому объекту, метод может принимать следующие значения:

GET, HEAD, POST, PUT и др.

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

Пример

GET / HTTP/1.0 — простейший запрос. Запрашивается корневой файл из корневой директории web-сервера.

HEAD – аналогичен методу GET, за исключением того, что в ответе сервер не возвращает Тело-Ответа. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса.

POST – применяется главным образом для модификации имеющегося ресурса или передачи данных обрабатывающему их процессу. Тело запроса содержит данные. Метод POST может изменять содержимое ресурса, поэтому не может считаться безопасным методом. Метод применяется для передачи данных CGI-скриптам из HTML форм. Сами данные следуют в последующих строках запроса в виде параметров. Реальная функция, выполняемая методом POST, определяется сервером и обычно зависит от URI-Запроса.

PUT – запрашивает сервер о сохранении Тело-Запроса под URI, равным URI-Запроса. Если URI-Запроса ссылается на уже существующий ресурс, Тело-Запроса должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URI-Запроса не существует, и данный URI может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URI.



Пример

PUT /path/filename.html HTTP/1.1 - такой вызов означает, что удаленный клиент хотел бы сохранить файл под именем /path/filename.html в дереве каталогов веб-сервера.

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

Существуют и другие методы, но на практике они практически не используются.

URI (Uniform Resource Identifiers) – универсальный идентификатор ресурса, в HTTP используется его частный вид — URL (Uniform Resource Locators), универсальный указатель ресурса. Он имеет вид:

http: // host [ : port ] [ path ]

host – доменное имя (или IP адрес) WEB сервера; если номер порта не указан, предполагается порт 80.

path — путь к ресурсу (информация о месте ресурса на сервере).

В URL также могут использоваться дополнительные параметры, описанные в RFC 1738.

Если ресурс – просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

Версия в настоящее время может принимать значения HTTP/1.0 или HTTP/1.1.

Заголовки запроса HTTP


Заголовки запроса могут фигурировать только в запросах. В последней версии протокола HTTP/1.1 двадцать заголовков запроса. Заголовки имеют формат:

Параметр: значение.

Для простоты восприятия удобно разбить заголовки запроса на четыре класса:

1. Предпочтения в ответе

Accept Предпочтительные типы содержимого

Accept-Charset Предпочтительные наборы символов

Accept-Encoding Предпочтительный метод кодирования содержимого

Accept-Language Предпочтительные языки

ТЕ Предпочтительные схемы кодирования при передаче



2. Информация, передаваемая вместе с запросом

Authorization Полномочия пользователя (логин/пароль)

From Адрес электронной почты пользователя

Referer URI, от которого получен URI запроса

User-Agent Информация о клиентском браузере

Proxy-Authorization Авторизация клиента прокси-сервером

Cookie Содержимое, хранящееся на стороне клиента

3. Условные запросы

If-Modified-Since Сравнение с временем последнего изменения

If-Match Сравнение на равенство идентификатора содержимого

If-None-Match Сравнение на неравенство идентификатора содержимого

If-Unmodified-Since Сравнение с временем последнего изменения

If-Range Отправить диапазон, только если содержимое изменено



4. Ограничения, накладываемые на сервер

Host Хост(домен) запрошенного ресурса

Expect Реакция сервера, ожидаемая клиентом

Max-Forwards Допустимое число прокси-серверов при передаче данных

Range Запрос диапазона содержимого

Например:



Accept – список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером :

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Полный перечень значений параметров для каждого заголовка приведен в RFC 2616 [6]



Достарыңызбен бөлісу:
1   2   3   4   5   6




©dereksiz.org 2024
әкімшілігінің қараңыз

    Басты бет