HTTP - это протокол передачи гипертекста между распределёнными системами. По сути, http является фундаментальным элементом современного Web-а. Как уважающие себя веб разработчики, мы должны знать о нём как можно больше.

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

Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1.

Основы HTTP

HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.

В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

Текущая версия протокола HTTP - 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.

URL

Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

Протокол может быть как http для обычных соединений, так и https для более безопасного обмена данными. Порт по умолчанию - 80. Далее следует путь к ресурсу на сервере и цепочка параметров.

Методы

С помощью URL, мы определяем точное название хоста, с которым хотим общаться, однако какое действие нам нужно совершить, можно сообщить только с помощью HTTP метода. Конечно же существует несколько видов действий, которые мы можем совершить. В HTTP реализованы самые нужные, подходящие под нужды большинства приложений.

Существующие методы:

GET : получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.

POST : используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.

PUT : обновить текущий ресурс. PUT запрос содержит обновляемые данные.

DELETE : служит для удаления существующего ресурса.

Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.

Также HTTP поддерживает и другие методы:

HEAD : аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE : во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS : используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

Коды состояния

В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант - это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

• 202 Accepted : запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
• 204 No Content : в теле ответа нет сообщения.
• 205 Reset Content : указание серверу о сбросе представления документа.
• 206 Partial Content : ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

3xx: Перенаправление

Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.

• 301 Moved Permanently : ресурс теперь можно найти по другому URL адресу.
• 303 See Other : ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
• 304 Not Modified : сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности - Enttity Tag);

4xx: Клиентские ошибки

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

• 400 Bad Request : вопрос был сформирован неверно.
• 401 Unauthorized : для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
• 403 Forbidden : сервер не открыл доступ к ресурсу.
• 405 Method Not Allowed : неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
• 409 Conflict : сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

• 501 Not Implemented : сервер не поддерживает запрашиваемую функциональность.
• 503 Service Unavailable : это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Форматы сообщений запроса/ответа

На следующем изображении вы можете увидеть схематично оформленный процесс отправки запроса клиентом, обработка и отправка ответа сервером.

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

Message = *() CRLF [] = Request-Line | Status-Line = Field-Name ":" Field-Value

Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

Общие заголовки

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

General-header = Cache-Control | Connection | Date | Pragma | Trailer | Transfer-Encoding | Upgrade | Via | Warning

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

Entity-header = Allow | Content-Encoding | Content-Language | Content-Length | Content-Location | Content-MD5 | Content-Range | Content-Type | Expires | Last-Modified

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

С помощью данных заголовков, можно задать нужную для ваших задач информацию.

Формат запроса

Запрос выглядит примерно так:

Request-Line = Method SP URI SP HTTP-Version CRLF Method = "OPTIONS" | "HEAD" | "GET" | "POST" | "PUT" | "DELETE" | "TRACE"

SP - это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Список возможных заголовков запроса:

Request-header = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | Expect | From | Host | If-Match | If-Modified-Since | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | TE | User-Agent

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

Формат ответа

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP версия
• Код статуса
• Сообщение статуса, понятное для человека

Обычный статус выглядит примерно так:

HTTP/1.1 200 OK

Заголовки ответа могут быть следующими:

Response-header = Accept-Ranges | Age | ETag | Location | Proxy-Authenticate | Retry-After | Server | Vary | WWW-Authenticate

• Age время в секундах, когда сообщение было создано на сервере.
• ETag MD5 сущности для проверки изменений и модификаций ответа.
• Location используется для перенаправления и содержит новый URL адрес.
• Server определяет сервер, где было сформирован ответ.

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

Инструменты для определения HTTP трафика

Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:

Наиболее часто используемый - это Chrome Developers Tools:

Если говорить об отладчике, можно воспользоваться Fiddler :

Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.

Библиотеки для работы с HTTP - jQuery AJAX

Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте .

Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

$.ajax({ url: "http://www.articles.com/latest", type: "GET", beforeSend: function (jqXHR) { jqXHR.setRequestHeader("Accepts-Language", "en-US,en"); } });

Если хотите обработать статус запроса, то это можно сделать так:

$.ajax({ statusCode: { 404: function() { alert("page not found"); } } });

Итог

Вот такой вот он, тур по основам протокола HTTP. Во второй части будет ещё больше интересных фактов и примеров.

Протокол передачи гипертекста (HTTP) - это основа жизни в Интернете. Он используется каждый раз при передаче документа или в запросе AJAX . Но HTTP на удивление мало известен некоторым веб-разработчикам.

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

Переизданный урок

Каждые несколько недель мы пересматриваем некоторые из любимых сообщений наших читателей за всю историю сайта. Этот урок впервые был опубликован в ноябре 2010 года.

Почему REST?

REST - простой способ организации взаимодействия между независимыми системами.

REST - простой способ организации взаимодействия между независимыми системами. Он пользуется популярностью с 2005 года и вдохновляет дизайн сервисов, таких как API Twitter. Благодаря тому, что REST обеспечивает взаимодействие с такими разнообразными клиентами, как мобильные телефоны и другие веб-сайты. Теоретически, REST не привязан к сети, но почти всегда реализован как таковой и был вдохновлен HTTP. В результате REST можно использовать везде, где возможен HTTP.

Альтернативой является создание относительно сложных соглашений поверх HTTP. Часто это принимает форму новых XML-языков. Самый яркий пример - SOAP . Вам нужно выучить совершенно новый набор соглашений, но вы никогда не используете HTTP в полную силу. Поскольку REST был вдохновлён HTTP и играет на его сильные стороны, это лучший способ узнать, как работает HTTP.

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

HTTP

HTTP - это протокол, который позволяет отправлять документы в Интернете.

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

В HTTP есть две разные роли: сервер и клиент. Как правило, клиент всегда инициирует разговор; сервер отвечает. HTTP основан на тексте; то есть сообщения по сути являются битами текста, хотя тело сообщения может также содержать другие носители. Использование текста позволяет легко отслеживать обмен HTTP.

HTTP-сообщения состоят из заголовка и тела. Тело часто может оставаться пустым; оно содержит данные, которые вы хотите передать по сети, чтобы использовать их в соответствии с инструкциями в заголовке. Заголовок содержит метаданные, например информацию о кодировке; но, в случае запроса, он также содержит важные HTTP-методы. В стиле REST вы обнаружите, что данные заголовка часто более значимы, чем тела.

Шпионство HTTP на работе

Если вы используете Chrome Developer Tools или Firefox с расширением Firebug , щелкните на панели Net и установите его в enabled . После этого у вас будет возможность просматривать информацию о HTTP-запросах по мере вашего поиска. Например:

Другим полезным способом ознакомиться с HTTP является использование выделенного клиента, такого как cURL.

GET

GET - это самый простой тип HTTP-запроса; которым браузер пользуется каждый раз, когда вы нажимаете ссылку или вводите URL-адрес в адресную строку. Он инструктирует сервер передавать клиенту данные, идентифицированные URL-адресом. Никогда не последует изменений данных на стороне сервера в результате запроса GET . В этом смысле GET -запрос доступен только для чтения, но, конечно, как только клиент получит данные, он может самостоятельно выполнять любые операции с ними, например, форматировать для отображения.

PUT

Запрос PUT используется, когда вы хотите создать или обновить ресурс, указанный URL-адресом. Например,

PUT /clients/robin

может создать клиента с именем Robin на сервере. Вы заметите, что REST полностью независим от бэкэнда; в запросе нет ничего, что информирует сервер о том, как данные должны создаваться - просто так должно быть. Это позволяет вам легко менять базовую технологию по необходимости. Запросы PUT содержат данные для использования при обновлении или создании ресурса в body. В cURL вы можете добавить данные в запрос с помощью -d .

Curl -v -X PUT -d "some text"

DELETE

DELETE должен выполнять противоположное PUT ; его следует использовать, если вы хотите удалить ресурс, указанный URL-адресом запроса.

Curl -v -X DELETE /clients/anne

Это приведёт к удалению всех данных, связанных с ресурсом, идентифицированных /clients/anne .

POST

POST используется, когда обработка, которую вы хотите выполнить на сервере, должна повторяться, если запрос POST повторяется (то есть, они не являются идемпотентными , подробнее об этом ниже). Кроме того, POST -запросы должны вызывать обработку body запроса как подчинённого URL-адреса, который вы отправляете.

Проще говоря:

POST /clients/

не должен вызывать изменение ресурса в /clients/ сам, но ресурс URL начинается с него /clients/ . Например, он может добавить в список нового клиента, с id , сгенерированным сервером.

/clients/some-unique-id

Запросы PUT легко используются вместо запросов POST и наоборот. Некоторые системы используют только один, некоторые используют POST для создания операций и PUT для операций обновления (поскольку с запросом PUT вы всегда указываете полный URL-адрес), некоторые используют POST для обновлений и PUT для создания.

Часто запросы POST используются для запуска операций на сервере, которые не вписываются в парадигму Create/Update/Delete ; но это, однако, выходит за рамки REST . В нашем примере мы будем полностью придерживаться PUT .

Классификация методов HTTP

Безопасные и небезопасные методы:

безопасными являются методы, которые никогда не изменяют ресурсы. Единственными безопасными методами, из четырёх перечисленных выше, является GET . Другие небезопасны, так как они могут привести к модификации ресурсов.

Idempotent методы:

Эти методы достигают того же результата, независимо от того, сколько раз запрос повторяется: это GET , PUT и DELETE . Единственным неидемпотентным методом является POST . PUT и DELETE , считающиеся идемпотентами, могут быть неожиданными, хотя, на самом деле, это довольно легко объяснить: повторение метода PUT с точно таким же body должно модифицировать ресурс таким образом, чтобы он оставался идентичным описанному в предыдущем запросе PUT: ничего не изменится! Аналогичным образом, нет смысла дважды удалять ресурс. Из этого следует, что независимо от того, сколько раз запрос PUT или DELETE повторяется, результат должен быть таким же, как если бы это было сделано только один раз.

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

Представительства

HTTP-клиент и HTTP-сервер обмениваются информацией о ресурсах, определённых URL-адресами.

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

Мы говорим, что запрос и ответ содержат представление ресурса. Под представлением мы подразумеваем информацию в определённом формате о состоянии ресурса или о том, каким это состояние должно быть в будущем. Оба, и header, и body - являются частями представления.

Заголовки HTTP, содержащие метаданные, жёстко определяются спецификацией HTTP; они могут содержать только простой текст и должны быть отформатированы определённым образом.

Тело может содержать данные в любом формате, и именно здесь видна сила HTTP. Вы знаете, что можете отправлять простой текст, изображения, HTML и XML на любом человеческом языке. Через метаданные запроса или различные URL-адреса вы можете выбирать между различными представлениями для одного и того же ресурса. Например, вы можете отправить веб-страницу в браузеры и JSON в приложения.

HTTP-ответ должен указывать тип содержимого body. Это делается в заголовке, в поле Content-Type ; например:

Content/Type: application/json

Для простоты наше приложение только отправляет JSON туда и обратно, но приложение должно быть спроектировано таким образом, чтобы вы могли легко изменять формат данных, чтобы адаптироваться для разных клиентов или предпочтений пользователя.

Библиотеки клиента HTTP

cURL - это, чаще всего, HTTP-решение для PHP-разработчиков.

Чтобы поэкспериментировать с различными методами запроса, вам нужен клиент, который позволит указать, какой метод использовать. К сожалению, формы HTML не подходят для счёта, так как они позволяют делать только запросы GET и POST. В реальной жизни API-интерфейсы доступны программно через отдельное клиентское приложение или через JavaScript в браузере.

Именно поэтому в дополнение к серверу важно иметь хорошие возможности HTTP-клиента на выбранном вами языке программирования.

Очень популярная клиентская HTTP-библиотека, опять же, cURL. Вы уже были ознакомлены с командой cURL ранее в этом уроке. CURL включает в себя как автономную программу командной строки, так и библиотеку, которая может использоваться различными языками программирования. В частности, cURL является, чаще всего, идеальным решением HTTP-клиента для разработчиков PHP. Другие языки, такие как Python, предлагают больше собственных клиентских HTTP-библиотек.

Настройка примера приложения

Я хочу показать как можно более низкий уровень функциональности.

Наш пример PHP-приложения чрезвычайно тощ. Я хочу выставить как можно более низкоуровневую функциональность, без какой-либо магии framework . Я также не хотел использовать настоящий API, например, Twitter, потому что они могут неожиданно меняться, вам нужно настроить аутентификацию, что может быть проблемой и вы не сможете изучить реализацию.

Чтобы запустить пример приложения, вам необходимо установить PHP5 и веб-сервер с механизмом для запуска PHP. Текущая версия должна быть не ниже версии 5.2, чтобы иметь доступ к функциям json_encode () и json_decode () .

Что касается серверов, наиболее распространенным вариантом является Apache с mod_php , но вы можете использовать любые альтернативы, которые вам удобны. Существует пример конфигурации Apache, который содержит правила перезаписи, которые помогут вам быстро настроить приложение. Все запросы к любому URL, начиная с /clients/, должны быть направлены в наш файл server.php .

В Apache вам нужно включить mod_rewrite и поместить прилагаемую конфигурацию mod_rewrite где-нибудь в вашей конфигурации Apache или в ваш файл .htacess . Таким образом, server.php будет отвечать на все запросы, поступающие с сервера. То же самое должно быть достигнуто с Nginx, или с любым другим сервером, который вы решите использовать.

Как работает пример приложения

Есть два ключа по обработке запросов REST. Первый ключ - инициировать различную обработку, в зависимости от метода HTTP, даже когда URL-адреса одинаковы. В PHP в глобальном массиве $ _SERVER есть переменная, которая определяет, какой метод был использован для выполнения запроса:

$_SERVER["REQUEST_METHOD"]

Эта переменная содержит имя метода в виде строки, например " GET ", " PUT " и далее.

Другой ключ - узнать, какой URL был запрошен. Для этого мы используем другую стандартную переменную PHP:

$_SERVER["REQUEST_URI"]

Эта переменная содержит URL-адрес, начинающийся с первой косой черты. Например, если имя хоста - " example.com ", " http://example.com/ " вернётся " / ", как " http://example.com/test/ " вернётся " /test/ ".

Давайте сначала попытаемся определить, какой URL-адрес был вызван. Мы рассматриваем только URL-адреса, начинающиеся с " clients ". Все остальные недействительны.

$resource = array_shift($paths); if ($resource == "clients") { $name = array_shift($paths); if (empty($name)) { $this->handle_base($method); } else { $this->handle_name($method, $name); } } else { // We only handle resources under "clients" header("HTTP/1.1 404 Not Found"); }

У нас есть два возможных результата:

• Ресурс - это клиенты, и в этом случае мы возвращаем полный список
• Существует еще один идентификатор

Если есть ещё один идентификатор, мы предполагаем, что это имя клиента, и, опять же, перенаправляем его в другую функцию, в зависимости от method . Мы используем оператор switch , которого следует избегать в реальном приложении:

Switch($method) { case "PUT": $this->create_contact($name); break; case "DELETE": $this->delete_contact($name); break; case "GET": $this->display_contact($name); break; default: header("HTTP/1.1 405 Method Not Allowed"); header("Allow: GET, PUT, DELETE"); break; }

Коды ответов

Коды ответа HTTP стандартизируют способ информирования клиента о результате его запроса.

Вы могли заметить, что пример приложения использует PHP header() , передавая некоторые странные строки в качестве аргументов. Функция header() печатает HTTP headers и гарантирует, что они отформатированы соответствующим образом. Заголовки должны быть первым в ответе, поэтому не стоит выводить что-либо ещё до того, как вы закончите с заголовками. Иногда ваш HTTP-сервер может быть настроен для добавления других заголовков в дополнение к тем, которые вы указали в коде.

Сервер должен вернуть наиболее подходящий код ответа HTTP; таким образом клиент может попытаться исправить свои ошибки, если они есть. Большинство людей знакомы с распространенным кодом ответа 404 Not Found , однако есть много более доступных, в соответствии множеству ситуаций.

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

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

200 OK

Этот код ответа указывает, что запрос был успешным.

201 Created

Это означает, что запрос был успешным и был создан ресурс. Он используется в случае успеха запроса PUT или POST .

400 Bad Request

Запрос был утерян. Это происходит особенно с запросами POST и PUT , когда данные не проходят валидацию или находятся в неправильном формате.

404 Not Found

Этот ответ указывает, что необходимый ресурс не найден. Обычно это относится ко всем запросам, которые указывают на URL-адрес без соответствующего ресурса.

401 Unauthorized

Эта ошибка означает, что вам необходимо выполнить проверку подлинности перед доступом к ресурсу.

405 Method Not Allowed

Используемый метод HTTP не поддерживается для этого ресурса.

409 Conflict

Это указывает на конфликт. Например, вы используете запрос PUT для создания одного и того же ресурса дважды.

500 Internal Server Error

Когда всё остальное терпит неудачу; как правило, ответ 500 используется, когда обработка завершается неудачно из-за непредвиденных обстоятельств на стороне сервера, что вызывает ошибку сервера.

Выполнение образца приложения

Давайте начнем с простого извлечения информации из приложения. Нам нужны детали клиента, " jim ", поэтому давайте отправим простой запрос GET на URL этого ресурса:

Curl -v http://localhost:80/clients/jim

Это отобразит полные сообщения headers. Последней строкой ответа будет body сообщения; в этом случае это будет JSON, содержащий адрес Jim (помните, что пропуск имени метода приведет к GET -запросу, а также замените localhost: 80 на имя сервера и порт, который вы используете).

Затем мы можем получить информацию для всех клиентов одновременно:

Curl -v http://localhost:80/clients/

Чтобы создать нового клиента с именем Paul ...

Curl -v -X PUT http://localhost:80/clients/paul -d "{"address":"Sunset Boulevard" }

и вы получите список всех клиентов, содержащих Paul в качестве подтверждения.

Наконец, чтобы удалить клиента:

Curl -v -X DELETE http://localhost:80/clients/anne

Вы обнаружите, что возвращённый JSON больше не содержит никаких данных об Anne.

Если вы пытаетесь получить несуществующего клиента, например:

Curl -v http://localhost:80/clients/jerry

Вы получите ошибку 404, в то время как при попытке создать уже существующего клиента:

curl -v -X PUT http://localhost:80/clients/anne

вместо этого получите ошибку 409.

Заключение

В общем, чем меньше предположений за пределами HTTP вы делаете, тем лучше.

Важно помнить, что HTTP был задуман для взаимодействия между системами, которые ничто не разделяет, кроме понимания протокола. В целом, чем меньше допущений за пределами HTTP вы делаете, тем лучше: это позволяет широкому кругу программ и устройств получать доступ к вашему API.

Я использовал PHP в этом уроке, потому что это, скорее всего, язык, наиболее знакомый читателям Nettuts +. Тем не менее, PHP, хотя и предназначен для Интернета, вероятно, не самый лучший язык для работы при REST-способе, поскольку он обрабатывает запросы PUT совсем иначе, чем GET и POST .

Помимо PHP, вы можете принять во внимание следующее:

• Различные Ruby frameworks (Rails и Sinatra)
• В Python есть отличная поддержка REST. Должны работать Plain Django и WebOb , или Werkzeug .
• node.js отлично поддерживает REST

Среди приложений, которые пытаются придерживаться принципов REST, классическим примером является Atom Publishing Protocol , хотя на самом деле он не используется слишком часто на практике. За современным приложением, основанным на философии использования HTTP в полной мере, обратитесь к Apache CouchDB .

В этой статье мы рассмотрим структуру HTTP-сообщений и проанализируем, что происходит за кадром при просмотре веб-страниц.

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

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

HTTP-запросы

Простой HTTP-запрос:

Рисунок 1: Элементарный HTTP-запрос

GET – HTTP-метод

/ - Путь к ресурсу

HTTP/1.1 – Версия протокола HTTP

HTTP-методы:

Протокол HTTP поддерживает несколько методов. В самой первой версии HTTP/1.0 было три метода: GET, POST и HEAD. В HTTP/1.1 появилось несколько новых методов (см. RFC 2616): OPTIONS, CONNECT, TRACE, PUT и DELETE. В RFC 5789, появившегося в 2010 году, добавился метод PATCH.

Рисунок 2: Перечень методов, поддерживаемых протоколом HTTP/1.1

GET используется для простого запроса ресурсов с веб-сервера. Параметры для этого метода передаются через URL.

POST используется для отсылки данных на веб-сервер через тело HTTP-запроса.

HEAD схож с методом GET, но выводит только заголовки HTTP-ответа, который возвращает сервер.

OPTIONS используется для получения списка методов, принимаемых веб-сервером, которые хранятся в заголовке ‘Allow’ в HTTP-ответе.

PUT предназначен для замены существующего или создания нового ресурса на веб-сервере.

TRACE используется при тестировании и отсылает полное сообщение, полученное веб-сервером, обратно клиенту, что позволяет увидеть конкретное содержимое, полученное веб-сервером.
CONNECT используется редко и совместно с прокси-сервером, который может динамически переключаться в режим туннеля.

PATCH схож с методом PUT. Отличие заключается в этом, что PATCH поддерживает частичную модификацию, в то время как метод PUT поддерживает только полную замену ресурса.

Примечание:

В большинстве приложений используются в основном GET и POST, поскольку HTML поддерживает только эти два метода. Если предполагается использование методов OPTIONS, PUT, DELETE, PATCH, TRACE или CONNECT, необходимо все тщательно продумать и оценить риски в отношении приложения или веб-сервера.

URL или Uniform Resource Locator (унифицированный указатель ресурсов) является подмножеством унифицированных идентификаторов ресурсов (Uniform Resource Identifiers; URI). Типичная структура URL выглядит так:

:///?&

По сути, это способ обозначения местонахождения сетевого ресурса и метод передачи данных целевому ресурсу.

Рисунок 3: Переменная HOST представляет собой сетевой адрес веб-сервера, куда клиент отсылает HTTP-запрос

Рисунок 4: Наиболее распространенные заголовки HTTP-запроса

User-Agent содержит информацию о браузере.

Accept определяет тип содержимого, который может принять клиент.

Accept-Encoding определяет тип кодировки, которую может принять клиент.

Content-Length определяет длину тела запроса в октетах. Это значение не имеет особой важности, но некоторые HTTP-методы (например, PUT) требуют этот заголовок. Если необходимо, в значение этого заголовка можно установить 0.
Referer содержит URL-источник запроса.

Cookie предназначен для отправки cookies на сервер для управления сессией.

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

Authorization содержит информацию, имеющую отношение к аутентификации на конкретной платформе.

HTTP-ответы

Пример простого HTTP-ответа:

Рисунок 5: Элементарный HTTP-ответ

В примере выше обратим особое внимание на первую строчку, где указана используемая HTTP-версия и код статуса, возвращенный сервером. Код статуса – важная часть HTTP-сообщения, поскольку свидетельствует о том, как приложение обработало запрос.

Рисунок 6: Перечень кодов статуса

Код ответа «100 Continue» редко когда-либо используется. Наиболее распространенный код «200 OK», который сигнализирует о том, что запрос корректен, ресурс существует, сервер обработал запрос и вернул ресурс в теле ответа. Код 201 означает, что ресурс, запрашиваемый в запросе, был успешно создан. Этот код обычно является результатом запроса с использованием метода PUT. Коды статуса 3xx возвращается приложениями со ссылкой на ресурс, куда нужно перенаправить клиента. Ссылка находится либо в тебе ответа, либо в заголовке «location». Коды статуса 4xx отсылаются в случае, если запрашиваемого ресурса на сервере не существует или пользователь не авторизован для получения содержимого или при возникновении ошибки в запросе, отправленном серверу. Коды статуса 5xx возвращаются в случае, когда сервере возникает ошибка, и нет возможности обработать запрос.

Рисунок 7: Наиболее распространенные HTTP-заголовки ответов

Date содержит дату, когда получен запрос.

Server содержит информацию о веб-сервере (например, IIS/Apache).

X-Powered-By содержит информацию, касающуюся технологии, используемой в скриптах, и текущую версию (например, PHP или Asp.net).

Content-Length схож с аналогичным заголовком в запросе. Содержит длину тела ответа в октетах.

Set-Cookie содержит cookie, используемые клиентом при формировании запроса с целью управления сессией.

Expires содержит, время по истечению которого сервер не будет рассматривать ответ как корректный.

Cache-Control указывает клиенту, нужно ли кэшировать возвращаемые запросы.

Пример HTTP-запроса с использованием метода GET:

Рисунок 8: Пример использования метода GET

Как видно на рисунке выше, в первой строчке указан метод, путь к ресурсу с параметрами и используемая версия HTTP. Во второй строчке указан хост, которому посылается запрос. В третьей строке содержится информация о браузере клиента. В четвертной строчке указан тип данных, который может принимать клиент. В пятой строчке указан язык, используемый клиентом. В шестой – cookie, полученные с сервера для поддержания сессии. Седьмая строчка указывает, нужно ли закрывать сессию или оставить открытой. Последняя строчка нужна при использовании метода GET и является пустой.

Пример ответа на запрос с использованием метода GET:

Рисунок 9: Ответ на запрос с использованием метода GET

В ответе на запрос содержится несколько HTTP-заголовков, которые уже обсуждались ранее.

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

Рисунок 10: Пример отправки информации методом POST

HTTP-запрос с использованием метода POST во многом схож с запросом с методом GET, который мы только что рассматривали. Основное отличие заключается в том, что параметры передаются не через URL, а через тело запроса. Этот метод более безопасен и пригоден для передачи конфиденциальной информации, поскольку передаваемые сведения нельзя получить из кэша на стороне клиента. Если планируется передавать параметры, имеющие отношение к аутентификации, следует использовать протокол HTTPS вместе с TLS с целью включения функции шифрования передаваемой информации. Заголовок Content-Length содержит длину тела запроса в октетах. И, наконец, заголовок Referer указывает серверу место возникновения запроса.

Пример HTTP-запроса с методом TRACE:

TRACE:

Рисунок 12: Ответ на запрос с методом TRACE

Как видно из рисунка выше, при использовании метода TRACE сервер возвращает в теле ответа все, что было отправлено в запросе. Эта функция может быть полезна в том случае, если клиенту нужно точно знать, что получено сервером. Метод TRACK выполняет ту же самую функцию, но используется при работе с сервером Microsoft IIS. Уязвимости, которые могут возникать при использовании метода TRACE, связаны с межсайтовой трассировкой (Cross-Site Tracing; XST). Этот класс брешей злоумышленник может использовать для кражи cookie или другой конфиденциальной информации (например, учетных записей), хранимых в заголовке Authorization при помощи межсайтового скриптинга (XSS).

Пример HTTP-запроса с методом PUT:

Рисунок 13: Создание простейшей страницы при помощи метода PUT

Метод PUT требует использования в запросе заголовка Content-Length. Значение этого заголовка особого значение не имеет и может быть установлено нулевым без каких-либо непредсказуемых последствий. Если директория, указанная в URL, уже существует на сервере, соответствующий ресурс будет полностью заменен. Если ресурса, указанного в URL, не существует, то будет создан новый ресурс (предполагается, что соответствующий метод реализован на сервере). Содержимое ресурса, который нужно создать, указывается в теле запроса. В примере выше создается простая html-страница.

Пример ответа на запрос с методом PUT:

Рисунок 14: Ответ с кодом об успешном создании страницы

В идеале от сервера должен прийти ответ с кодом статуса «201 Created», свидетельствующий о том, что ресурс создан. Кроме того, в HTTP-запрос можно было бы вставить заголовок «Expect: 100-continue», чтобы удостовериться, что сервер готов к обработке и не закроет сокет до того, как получит содержимое, которое вы указали в теле запроса. При использовании в запросе заголовка «Expect» в ответ может прийти один из двух кодов статуса: «100 Continue» или «417 Expectation Failed».

После ознакомления с вышеуказанной информации становится понятно, почему этот метод может стать причиной потенциальных проблем и привести к тому, что злоумышленник завладеет вашим сервером. В реальных условиях использование метода PUT разрешено нечасто, и для того, чтобы сервер принял содержимое тело запроса, необходимо наличие заголовка «Authorization».

Пример атаки показан на рисунке ниже. В этом примере в тело HTTP-запроса вставляется код шелла, который, в случае принятия запроса сервером, позволяет злоумышленнику выполнять команды.

Пример HTTP-запроса с методом PUT и вставкой кода шелла:

Рисунок 15: Пример использования кода шелла в теле запроса

Пример HTTP-запроса с методом DELETE:

Рисунок 15: Запрос на удаление ресурса при помощи метода DELETE

Пример ответа на запрос с методом DELETE:

Рисунок 16: Ответ на запрос об успешном удалении ресурса

После успешного удаления ресурса, указанного в URL, сервер должен вернуть код статуса 200 OK.

Пример HTTP-запроса с методом OPTIONS:

Пример ответа на запрос с методом OPTIONS:

Рисунок 18: Ответ с перечнем методов, доступных на сервере

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

В данной статье была представлена информация относительно использования HTTP-сообщений и методов, реализованных в протоколе HTTP/1.1. Кроме того, затрагивалась информация о возможных сценариях атак против веб-приложений при помощи этих методов. Эти сведения могут помочь вам в разработке сценариев пентестов. Надеемся, что после ознакомления с этой заметкой, вы стали лучше понимать механизмы функционирования и потоков данных протокола HTTP.

15 ответов

HTTP PUT:

PUT помещает файл или ресурс в определенный URI и точно в этот URI. Если в этом URI уже есть файл или ресурс, PUT заменяет этот файл или ресурс. Если там нет файла или ресурса, PUT создает его. PUT idempotent , но парадоксально ответы PUT не кэшируемы.

HTTP POST:

POST отправляет данные в определенный URI и ожидает, что ресурс в этом URI обрабатывает запрос. Веб-сервер в этот момент может определить, что делать с данными в контексте указанного ресурса. Метод POST не idempotent , однако ответы POST могут быть кэшируемыми, если сервер устанавливает соответствующие заголовки Cache-Control и Expires.

Официальный HTTP RFC определяет POST как:

• Аннотация существующих ресурсов;
• Размещение сообщения на доске объявлений, в новостной группе, в списке рассылки, или аналогичная группа статей;
• Предоставление блока данных, например, результата отправки формы, к процессу обработки данных;
• Расширение базы данных с помощью операции добавления.

Разница между POST и PUT:

Сам RFC объясняет основную разницу:

Основное различие между Запросы POST и PUT отражены в различный смысл Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать закрытую сущность. Что ресурсом может быть прием данных процесс, шлюз для некоторых других протокол или отдельный объект, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, прилагаемый к запросу - пользовательский агент знает, что такое URI и сервер НЕ ДОЛЖЕН попытка применить запрос к другой ресурс. Если сервер желает что запрос будет применен к другой URI, он ДОЛЖЕН отправить 301 (перемещенный постоянный) ответ; пользовательский агент МОЖЕТ затем сделать его собственное решение относительно того, следует ли перенаправить запрос.

Использование правильного метода, не связанного в стороне:

Только семантика.

Предполагается, что HTTP PUT принимает тело запроса, а затем сохраняет его на ресурсе, идентифицированном URI.

HTTP POST является более общим. Предполагается инициировать действие на сервере. Это действие может состоять в том, чтобы сохранить тело запроса в ресурсе, идентифицированном URI, или это может быть другой URI, или это может быть другое действие.

PUT , например . Помещенный в URI влияет именно на этот URI. POST для URI может вообще иметь какой-либо эффект.

Чтобы привести примеры ресурсов стиля REST:

"POST/books" с кучей информации о книге может создать новую книгу и ответить новым URL-адресом, идентифицирующим эту книгу: "/books/5".

"PUT/books/5" придется либо создать новую книгу с идентификатором 5, либо заменить существующую книгу с идентификатором 5.

В стиле non-resource POST можно использовать практически для всего, что имеет побочный эффект. Еще одно отличие состоит в том, что PUT должен быть идемпотентным - несколько PUT одинаковых данных для одного и того же URL-адреса должны быть точными, если несколько POST могут создавать несколько объектов или что-то, что делает ваше POST-действие.

1) GET: - используется, когда клиент запрашивает ресурс на веб-сервере.

2) HEAD: - используется, когда клиент запрашивает некоторую информацию о ресурсе, но не запрашивает сам ресурс.

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

4) PUT: - Используется, когда клиент отправляет заменяющий документ или загружает новый документ на веб-сервер под URL-адресом запроса.

5) DELETE: - Используется, когда клиент пытается удалить документ с веб-сервера, указанный URL-адресом запроса.

6) TRACE: - Используется, когда клиент просит доступные прокси или промежуточные серверы изменять запрос, чтобы объявить себя.

7) ОПЦИИ: - Используется, когда клиент хочет определить другие доступные методы для извлечения или обработки документа на веб-сервере.

8) CONNECT: - Используется, когда клиент хочет установить прозрачное соединение с удаленным хостом, как правило, для обеспечения SSL-шифрованной связи (HTTPS) через прокси-сервер HTTP.

Другие уже опубликовали отличные ответы, я просто хотел добавить, что с большинством языков, фреймворков и прецедентов вы будете иметь дело с POST много, гораздо чаще, чем PUT. К моменту, когда PUT, DELETE и т.д. Являются в основном пустяковыми вопросами.

Согласно RFC , разница между PUT и POST находится в URI запроса. URI, идентифицированный POST, определяет объект, который будет обрабатывать запрос POST. URI в запросе PUT включает объект в запрос. Таким образом, POST /v1/coffees/orders означает создание нового ресурса и возврат идентификатор для описания ресурса. Напротив, PUT /v1/coffees/orders/1234 означает обновление ресурса, идентифицированного " 1234 ", если оно существует; иначе создайте новый порядок и используйте URI orders/1234 , чтобы идентифицировать его.

PUT and POST can both be used to create or update methods. The usage of the method depends on the idempotent behavior expected from the method as well as the location of the resource to identify it.

POST считается чем-то вроде метода типа factory. Вы включаете данные с ним, чтобы создать то, что хотите, и все, что находится на другом конце, знает, что с ним делать. PUT используется для обновления существующих данных по указанному URL-адресу или для создания чего-то нового, когда вы знаете, что будет URI, и он еще не существует (в отличие от POST, который создаст что-то и вернет URL-адрес при необходимости).

В последнее время меня очень раздражает популярное заблуждение веб-разработчиков, что POST используется для создания ресурса, а PUT используется для обновления/изменения.

Если вы посмотрите на страницу 55 RFC 2616 ("Протокол передачи гипертекста - HTTP/1.1"), раздел 9.6 ("PUT"), вы увидите что PUT действительно для:

Метод PUT запрашивает, чтобы закрытый объект был сохранен в поставляемом Request-URI.

Theres также удобный абзац, чтобы объяснить разницу между POST и PUT:

Основное различие между запросами POST и PUT отражается в различном значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать заключенный объект. Этот ресурс может быть процессом принятия данных, шлюзом к другому протоколу или отдельным объектом, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом - пользовательский агент знает, что такое URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к другому ресурсу.

В нем ничего не говорится о различии между обновлением/созданием, потому что это не о чем. О различии между этим:

Obj.set_attribute(value) # A POST request.

Obj.attribute = value # A PUT request.

Поэтому, пожалуйста, прекратите распространение этого популярного заблуждения. Прочтите свои RFC.

REST просит разработчиков использовать методы HTTP явно и таким образом, чтобы это соответствовало определению протокола. Этот базовый принцип проектирования REST устанавливает взаимно-однозначное сопоставление между операциями создания, чтения, обновления и удаления (CRUD) и методами HTTP. Согласно этому отображению:

Чтобы создать ресурс на сервере, используйте POST.

Чтобы получить ресурс, используйте GET.

Чтобы изменить состояние ресурса или обновить его, используйте PUT.

Чтобы удалить или удалить ресурс, используйте DELETE.

При разработке процедуры отправки на сайт информации из 1С с версией платформы 8.3.9.2170 столкнулся с проблемой: разработчик сайта предоставил мне возможность записывать нужную информацию только при помощи HTTP запроса методом PUT.

Недолго думая, я набросал простенький код:

Соединение = Новый HTTPСоединение("www.mysite.ru"); Заголовки = Новый Соответствие; Заголовки["Content-Type"] = "application/x-www-form-urlencoded"; Запрос = Новый HTTPЗапрос("/api/order_items/93076?order_item=30", Заголовки); Соединение.Записать(Запрос);

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

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

Сразу же выяснилась странная вещь: вышеприведенный код генерирует не PUT, а HEAD запрос!

В логах апача я увидел следующее:

127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"

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

Соединение.ВызватьHTTPМетод("PUT",Запрос);

В логах то же самое:

127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"

"Может быть я что-то не так делаю?" - задал я себе вопрос. Но в интернете и в мануалах не было никаких подсказок. Что ж, метод научного тыка еще никто не отменял. Для начала я попробовал сделать так:

Соединение.ВызватьHTTPМетод("фывфыв",Запрос);

В логах получил:

127.0.0.1 - - "?????? /api/order_items/93076?order_item=30 HTTP/1.1"

Любопытно, значит 1С заменяет конкретно метод PUT (чем же он 1С не угодил?).

После еще нескольких попыток я пришел к варианту:

Соединение.ВызватьHTTPМетод("PUT ",Запрос);

В логах получил:

127.0.0.1 - - "PUT /api/order_items/93076?order_item=30 HTTP/1.1"

И уже этот вариант отработал на сайте и все остались довольны.

Подсказал более корректное решение проблемы: необходимо задать тело запроса, любое, даже пустое. Например, сработает такой вариант:

Соединение = Новый HTTPСоединение("www.mysite.ru"); Заголовки = Новый Соответствие; Заголовки["Content-Type"] = "application/x-www-form-urlencoded"; Запрос = Новый HTTPЗапрос("/api/order_items/93076?order_item=30", Заголовки); Запрос.УстановитьТелоИзСтроки("", КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать); Соединение.Записать(Запрос);

И уже совсем правильно, наверное, передавать в теле запроса сами значения параметров.

Вывод следующий: PUT запрос без тела платформа 1С считает ошибочным и заменяет метод на HEAD.

Любопытно что POST запрос без тела 1С никак не отслеживает и не превращает в GET, проверял ради спортивного интереса.

Как сказал бы всем известный Вовочка из знаменитого анекдота: "Где логика?".

Надеюсь кому-то моя публикация сбережет несколько часов жизни в поисках ответа. =)))