Сети и системы телекоммуникаций. Погонин В.А - 93 стр.

UptoLike

ВУЗ: 

ТГТУ | Тамбов

Составители: 

Рубрика: 

Метод GET позволяет получать любую информацию (в форме объекта), идентифицирован-
ную запрашиваемым URI (Request-URI). Если запрашиваемый URI (Request-URI) обращается к
процессу, производящему данные, то в качестве объекта ответа должны быть возвращены произ-
веденные данные, а не исходный текст процесса, если сам процесс не выводит исходный текст.
Различается "условный GET" ("conditional GET"), при котором сообщение запроса включает
поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Ус-
ловный метод GET запрашивает передачу объекта, только если последний удовлетворяет услови-
ям, описанным в условных полях заголовка. Условный метод GET предназначен для уменьшения
неоправданной загрузки сети и позволяет обновлять кэшированные объекты без использова-
ния нескольких запросов или пересылки данных, уже сохраненных клиентом.
Различается также "частичный GET" ("partial GET"), при котором сообщение запроса вклю-
чает поле заголовка Range. Частичный GET запрашивает передачу только части объекта. Час-
тичный метод GET предназначен для уменьшения ненужной загрузки сети, и позволяет собирать
объекты из частей, без передачи частей данных, уже сохраненных клиентом.
Ответ на запрос GET кэшируем тогда и только тогда, когда он отвечает требованиям кэши-
рования в HTTP, описанным ниже.
9.4.9.4. HEAD
Метод HEAD идентичен GET, за исключением того, что сервер не должен возвращать в отве-
те тело сообщения (message-body). Метаинформации, содержащейся в HTTP заголовках ответа на
запрос HEAD следует быть идентичной информации, представляемой в ответ на запрос GET.
Этот метод может использоваться для получения метаинформации об объекте запроса без непо-
средственной пересылки тела объекта (entity-body) и часто используется для тестирования гипер-
текстовых связей в целях проверки достоверности, достижимости и времени модификации.
Ответ на запрос HEAD может быть кэшируемым в том смысле, что информация, содержа-
щаяся в ответе, может использоваться для модифицикации предварительно кэшированного объ-
екта из этого ресурса. Если новые значения поля указывают, что кэшируемый объект отличается
от текущего объекта (по таким параметрам, как Content-Length, Content-MD5, ETag или Last-
Modified), то кэш должен обрабатывать содержимое как просроченное.
9.4.9.5. POST
Метод POST используется для запроса, при котором адресуемый сервер принимает объект,
включенный в запрос, как новое подчинение (subordinate) ресурса, идентифицированного запра-
шиваемым URI (Request-URI) в строке запроса (Request-Line). POST разработан для того, чтобы
общим методом реализовать следующие функции:
− аннотация существующих ресурсов;
− регистрация сообщения на электронной доске объявлений (bulletin board), в конференции
новостей (newsgroup), списке рассылки (mailing list) или подобной группе статей;
− передача блока данных, например результат ввода в форме, процессу обработки;
− расширение базы данных посредством конкатенирующей операции (append operation).
Фактически функция, выполняемая методом POST, определяется сервером и обычно зависит
от запрашиваемого URI (Request-URI). Объект, передаваемый методом POST, относится к этому
URI так же, как файл относится к каталогу, в котором он находится, статья относится к конфе-
ренции новостей (newsgroup), в которой она зарегистрирована, а запись относится к базе данных.
Действие, выполняемое методом POST, может не давать в качестве результата ресурс, кото-
рый можно было бы идентифицировать URI.
В этом случае, в зависимости от того, включает ли ответ объект, описывающий результат, или
нет, код состояния в ответе может быть как 200 (OK), так и 204 (Нет содержимого, No Content).
Если ресурс был создан на первоначальном сервере, ответу следует содержать код состояния
201 (Создан, Created) и включать объект, который описывает состояние запроса и ссылается на
новый ресурс, а также заголовок Locatio.

Страницы