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

UptoLike

ВУЗ: 

ТГТУ | Тамбов

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

Рубрика: 

кодом состояния, следует повторить запрос, но уже не ожидать ответа с кодом состояния 100
(Продолжать, Continue).
9.4.9. ОПРЕДЕЛЕНИЯ МЕТОДОВ
Множество общих для HTTP/1.1 методов (OPTIONS, GET, PUT и т.д.) приводится ниже. Хотя
это множество может быть расширено, нельзя считать, что дополнительные методы имеют оди-
наковую семантику, если они являются расширениями разных клиентов и серверов.
Поле заголовка запроса Host должно сопровождать все HTTP/1.1 запросы.
9.4.9.1. Безопасные и идемпотентные методы
Программистам следует понимать, что программное обеспечение при взаимодействии с Ин-
тернетом представляет пользователя, и программе следует информировать пользователя о любых
действиях, которые он может произвести, но которые могут иметь непредсказуемое значение для
него или других лиц.
В частности, было принято соглашение, что методы GET и HEAD никогда не должны иметь
иного значения, кроме загрузки (retrieval). Указанные методы следует рассматривать как "безо-
пасные". Это позволяет агенту пользователя представлять другие методы, такие как POST, PUT
и DELETE, таким образом, чтобы пользователь был проинформирован о том, что он запрашивает
выполнение потенциально опасного действия.
Естественно невозможно гарантировать, что сервер не генерирует побочных эффектов в ре-
зультате выполнения запроса GET; фактически, некоторые динамические ресурсы содержат та-
кую возможность. Важное различие здесь в том, что не пользователь запрашивает побочные эф-
фекты, и, следовательно, пользователь не может нести ответственность за них.
Методы могут также обладать свойством "идемпотентности" ("idempotence") в том смысле,
что побочные эффекты от N > 0 идентичных запросов такие же, как от одиночного запроса (за ис-
ключением ошибок и проблем устаревания). Методы GET, HEAD, PUT и DELETE обладают дан-
ным свойством.
9.4.9.2. OPTIONS
Метод OPTIONS представляет запрос информации об опциях соединения, доступных в це-
почке запросов/ответов, идентифицируемой запрашиваемым URI (Request-URI). Этот метод по-
зволяет клиенту определять опции и/или требования, связанные с ресурсом, или возможностями
сервера, но не производя никаких действий над ресурсом и не инициируя его загрузку.
Если ответ сервера – это не сообщение об ошибке, то ответ не должен содержать иной инфор-
мации объекта, кроме той, которую можно рассматривать как опции соединения (например Allow
– можно рассматривать как опцию соединения, а Content-Type – нет). Ответы на этот метод не
кэшируются.
Если запрашиваемый URI (Request-URI) – звездочка ("*"), то запрос OPTIONS предназначен
для обращения к серверу в целом. Если код состояния ответа – 200, то ответу следует содержать
любые поля заголовка, которые указывают опциональные возможности, реализуемые сервером
(например, Public), включая любые расширения, не определенные данной спецификацией, в до-
полнение к соответствующим общим полям или полям заголовка ответа (response-header). Как
описано в разделе 5.1.2, запрос "OPTIONS *" может быть применен через прокси-сервер с опреде-
лением адресуемого сервера в запрашиваемом URI (Request-URI) с пустым путем.
Если запрашиваемый URI (Request-URI) не звездочка ("*"), то запрос OPTIONS применяется
к опциям, которые доступны при соединении с указанным ресурсом. Если код состояния ответа –
200, то ответу следует содержать любые поля заголовка, которые указывают опциональные воз-
можности, реализуемые сервером и применимые к указанному ресурсу (например Allow), вклю-
чая любые расширения, не определенные данной спецификацией, в дополнение к соответствую-
щим общим полям или полям заголовка ответа (response-header). Если запрос OPTIONS переда-
ется через прокси-сервер, то последний редактирует ответ, исключая те опции, которые не преду-
смотрены возможностями этого прокси-сервера.
9.4.9.3. GET

Страницы