8-900-374-94-44
HTTP-метод POST предназначен для отправки данных на сервер. Тип тела запроса указывается в заголовке Content-Type.
Разница между PUT и POST состоит в том, что PUT является идемпотентным: повторное его применение даёт тот же результат, что и при первом применении (то есть у метода нет побочных эффектов), тогда как повторный вызов одного и того же метода POST может иметь такие эффекты, как например, оформление одного и того же заказа несколько раз.
Запрос POST обычно отправляется через форму HTML и приводит к изменению на сервере. element or the formenctype attribute of the <input> or <button> elements:»>В этом случае тип содержимого выбирается путём размещения соответствующей строки в атрибуте enctype элемента <form> или formenctype атрибута элементов <input> или
application/x-www-form-urlencoded: значения кодируются в кортежах с ключом, разделённых символом '&', с '=' между ключом и значением.
Не буквенно-цифровые символы — percent encoded: это причина, по которой этот тип не подходит для использования с двоичными данными (вместо этого используйте multipart/form-data)multipart/form-data: каждое значение посылается как блок данных («body part»), с заданными пользовательским клиентом разделителем («boundary»), разделяющим каждую часть. Эти ключи даются в заголовки Content-Disposition каждой частиtext/plainКогда запрос POST отправляется с помощью метода, отличного от HTML-формы, — например, через XMLHttpRequest — тело может принимать любой тип. Как описано в спецификации HTTP 1.1, POST предназначен для обеспечения единообразного метода для покрытия следующих функций:
| Запрос имеет тело | Да |
|---|---|
| Успешный ответ имеет тело | Да |
| Безопасный | Нет |
| Идемпотентный | Нет |
| Кешируемый | Только если включена информация о свежести сообщения |
| Допускается в HTML-формах | Да |
POST /index.html
Простая форма запроса, используя стандартный application/x-www-form-urlencoded content type:
POST / HTTP/1.1 Host: foo.com Content-Type: application/x-www-form-urlencoded Content-Length: 13 say=Hi&to=Mom
Форма запроса, используя multipart/form-data content type:
POST /test.html HTTP/1.1 Host: example.org Content-Type: multipart/form-data;boundary="boundary" --boundary Content-Disposition: form-data; name="field1" value1 --boundary Content-Disposition: form-data; name="field2"; filename="example.txt" value2 --boundary--
| Specification |
|---|
| HTTP Semantics # POST |
BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
txt"
value2
--boundary--
Content-TypeContent-DispositionWant to get more involved?
Learn how to contribute.
This page was last modified on by MDN contributors.
Большинство используемых нами веб- и мобильных приложений постоянно взаимодействуют с глобальной сетью. Почти все подобные коммуникации совершаются с помощью запросов по протоколу HTTP.
Рассказываем о них подробнее.
HTTP (HyperText Transfer Protocol, дословно — «протокол передачи гипертекста») представляет собой протокол прикладного уровня, используемый для доступа к ресурсам Всемирной Паутины. Под термином гипертекст следует понимать текст, в понятном для человека представлении, при этом содержащий ссылки на другие ресурсы.
Данный протокол описывается спецификацией RFC 2616. На сегодняшний день наиболее распространенной версией протокола является версия HTTP/2, однако нередко все еще можно встретить более раннюю версию HTTP/1.1.
В обмене информацией по HTTP-протоколу принимают участие клиент и сервер. Происходит это по следующей схеме:
По умолчанию для коммуникации по HTTP используется порт 80, хотя вместо него может быть выбран и любой другой порт.
Многое зависит от конфигурации конкретного веб-сервера.
Подробнее о протоколе HTTP читайте по ссылке →
Данные между клиентом и сервером в рамках работы протокола передаются с помощью HTTP-сообщений. Они бывают двух видов:
Само по себе сообщение представляет собой информацию в текстовом виде, записанную в несколько строчек.
В целом, как запросы HTTP, так и ответы имеют следующую структуру:
Как можно понять из названия, ее содержимое занимает ровно одну строчку.Рассмотрим атрибуты HTTP-запроса подробнее.
Стартовая строка HTTP-запроса состоит из трех элементов:
В примере ниже стартовая строка указывает, что в качестве метода используется GET, обращение будет произведено к ресурсу /index.html, по версии протокола HTTP/1.1:
Основные структурные элементы URL.Разберемся с каждым из названных элементов подробнее.
Методы позволяют указать конкретное действие, которое мы хотим, чтобы сервер выполнил, получив наш запрос. Так, некоторые методы позволяют браузеру (который в большинстве случаев является источником запросов от клиента) отправлять дополнительную информацию в теле запроса — например, заполненную форму или документ.
Ниже приведены наиболее используемые методы и их описание:
Разберемся с каждым из названных элементов подробнее.
| Метод | Описание |
| GET | Позволяет запросить некоторый конкретный ресурс. Дополнительные данные могут быть переданы через строку запроса (Query String) в составе URL (например ?param=value).О составляющих URL мы поговорим чуть позже. |
| POST | Позволяет отправить данные на сервер. Поддерживает отправку различных типов файлов, среди которых текст, PDF-документы и другие типы данных в двоичном виде. Обычно метод POST используется при отправке информации (например, заполненной формы логина) и загрузке данных на веб-сайт, таких как изображения и документы. |
| HEAD | Здесь придется забежать немного вперед и сказать, что обычно сервер в ответ на запрос возвращает заголовок и тело, в котором содержится запрашиваемый ресурс. Данный метод при использовании его в запросе позволит получить только заголовки, которые сервер бы вернул при получении GET-запроса к тому же ресурсу. Запрос с использованием данного метода обычно производится для того, чтобы узнать размер запрашиваемого ресурса перед его загрузкой. |
| PUT | Используется для создания (размещения) новых ресурсов на сервере. Если на сервере данный метод разрешен без надлежащего контроля, то это может привести к серьезным проблемам безопасности. |
| DELETE | Позволяет удалить существующие ресурсы на сервере. Если использование данного метода настроено некорректно, то это может привести к атаке типа «Отказ в обслуживании» (Denial of Service, DoS) из-за удаления критически важных файлов сервера. |
| OPTIONS | Позволяет запросить информацию о сервере, в том числе информацию о допускаемых к использованию на сервере HTTP-методов. |
| PATCH | Позволяет внести частичные изменения в указанный ресурс по указанному расположению. |
Получение доступа к ресурсам по HTTP-протоколу осуществляется с помощью указателя URL (Uniform Resource Locator). URL представляет собой строку, которая позволяет указать запрашиваемый ресурс и еще ряд параметров.
Использование URL неразрывно связано с другими элементами протокола, поэтому далее мы рассмотрим его основные компоненты и строение:
Поле Scheme используется для указания используемого протокола, всегда сопровождается двоеточием и двумя косыми чертами (://).
Host указывает местоположение ресурса, в нем может быть как доменное имя, так и IP-адрес.
Port, как можно догадаться, позволяет указать номер порта, по которому следует обратиться к серверу. Оно начинается с двоеточия (:), за которым следует номер порта. При отсутствии данного элемента номер порта будет выбран по умолчанию в соответствии с указанным значением Scheme (например, для http:// это будет порт 80).
Далее следует поле Path. Оно указывает на ресурс, к которому производится обращение. Если данное поле не указано, то сервер в большинстве случаев вернет указатель по умолчанию (например index.html).
Поле Query String начинается со знака вопроса (?), за которым следует пара «параметр-значение», между которыми расположен символ равно (=). В поле Query String могут быть переданы несколько параметров с помощью символа амперсанд (&) в качестве разделителя.
Не все компоненты необходимы для доступа к ресурсу. Обязательно следует указать только поля Scheme и Host.
Раз уж мы упомянули версию протокола как элемента стартовой строки, то стоит сказать об основных отличиях версий HTTP/1.X от HTTP/2.X.
Последняя стабильная, наиболее стандартизированная версия протокола первого поколения (версия HTTP/1.1) вышла в далеком 1997 году. Годы шли, веб-страницы становились сложнее, некоторые из них даже стали приложениями в том виде, в котором мы понимаем их сейчас.
Кроме того, объем медиафайлов и скриптов, которые добавляли интерактивность страницам, рос. Это, в свою очередь, создавало перегрузки в работе протокола версии HTTP/1.1.
Стало очевидно, что у HTTP/1.1 есть ряд значительных недостатков:
С выходом HTTP/2 было предложено следующее решение: HTTP/1.X-сообщения разбивались на так называемые фреймы, которые встраивались в поток данных.
Фреймы данных (тела сообщения) отделялись от фреймов заголовка, что позволило применять сжатие. Вместе с появлением потоков появился и ранее описанный механизм мультиплексирования — теперь можно было обойтись одним соединением для нескольких потоков.
Единственное о чем стоит сказать в завершение темы: HTTP/2 перестал быть текстовым протоколом, а стал работать с «сырой» двоичной формой данных. Это ограничивает чтение и создание HTTP-сообщений «вручную». Однако такова цена за возможность реализации более совершенной оптимизации и повышения производительности.
HTTP-заголовок представляет собой строку формата «Имя-Заголовок:Значение», с двоеточием(:) в качестве разделителя. Название заголовка не учитывает регистр, то есть между Host и host, с точки зрения HTTP, нет никакой разницы. Однако в названиях заголовков принято начинать каждое новое слово с заглавной буквы. Структура значения зависит от конкретного заголовка. Несмотря на то, что заголовок вместе со значениями может быть достаточно длинным, занимает он всего одну строчку.
В запросах может передаваться большое число различных заголовков, но все их можно разделить на три категории:
Ниже можно видеть пример заголовков в запросе:
| Заголовок | Описание |
| Host | Используется для указания того, с какого конкретно хоста запрашивается ресурс. В качестве возможных значений могут использоваться как доменные имена, так и IP-адреса. На одном HTTP-сервере может быть размещено несколько различных веб-сайтов. Для обращения к какому-то конкретному требуется данный заголовок. |
| User-Agent | Заголовок используется для описания клиента, который запрашивает ресурс. Он содержит достаточно много информации о пользовательском окружении. Например, может указать, какой браузер используется в качестве клиента, его версию, а также операционную систему, на которой этот клиент работает. |
| Refer | Используется для указания того, откуда поступил текущий запрос. Например, если вы решите перейти по какой-нибудь ссылке в этой статье, то вероятнее всего к запросу будет добавлен заголовок Refer: https://selectel.ru |
| Accept | Позволяет указать, какой тип медиафайлов принимает клиент. В данном заголовке могут быть указаны несколько типов, перечисленные через запятую (‘ , ‘). А для указания того, что клиент принимает любые типы, используется следующая последовательность — */*. |
| Cookie | Данный заголовок может содержать в себе одну или несколько пар «Куки-Значение» в формате cookie=value. Куки представляют собой небольшие фрагменты данных, которые хранятся как на стороне клиента, так и на сервере, и выступают в качестве идентификатора. Куки передаются вместе с запросом для поддержания доступа клиента к ресурсу. Помимо этого, куки могут использоваться и для других целей, таких как хранение пользовательских предпочтений на сайте и отслеживание клиентской сессии. Несколько кук в одном заголовке могут быть перечислены с помощью символа точка с запятой (‘ ; ‘), который используется как разделитель. |
| Authorization | Используется в качестве еще одного метода идентификации клиента на сервере. После успешной идентификации сервер возвращает токен, уникальный для каждого конкретного клиента. В отличие от куки, данный токен хранится исключительно на стороне клиента и отправляется клиентом только по запросу сервера. Существует несколько типов аутентификации, конкретный метод определяется тем веб-сервером или веб-приложением, к которому клиент обращается за ресурсом. |
Завершающая часть HTTP-запроса — это его тело. Не у каждого HTTP-метода предполагается наличие тела..gif)
Так, например, методам вроде GET, HEAD, DELETE, OPTIONS обычно не требуется тело. Некоторые виды запросов могут отправлять данные на сервер в теле запроса: самый распространенный из таких методов — POST.
HTTP-ответ является сообщением, которое сервер отправляет клиенту в ответ на его запрос. Его структура равна структуре HTTP-запроса: стартовая строка, заголовки и тело.
Строка статуса (Status line)Стартовая строка HTTP-ответа называется строкой статуса (status line). На ней располагаются следующие элементы:
Коды состояния HTTP используются для того, чтобы сообщить клиенту статус их запроса. HTTP-сервер может вернуть код, принадлежащий одной из пяти категорий кодов состояния:
| Категория | Описание |
| 1xx | Коды из данной категории носят исключительно информативный характер и никак не влияют на обработку запроса. |
| 2xx | Коды состояния из этой категории возвращаются в случае успешной обработки клиентского запроса. |
| 3xx | Эта категория содержит коды, которые возвращаются, если серверу нужно перенаправить клиента. |
| 4xx | Коды данной категории означают, что на стороне клиента был отправлен некорректный запрос. Например, клиент в запросе указал не поддерживаемый метод или обратился к ресурсу, к которому у него нет доступа. |
| 5xx | Ответ с кодами из этой категории приходит, если на стороне сервера возникла ошибка. |
Полный список кодов состояния доступен в спецификации к протоколу, ниже приведены только самые распространенные коды ответов:
| Категория | Описание |
| 200 OK | Возвращается в случае успешной обработки запроса, при этом тело ответа обычно содержит запрошенный ресурс. |
| 302 Found | Перенаправляет клиента на другой URL. Например, данный код может прийти, если клиент успешно прошел процедуру аутентификации и теперь может перейти на страницу своей учетной записи. |
| 400 Bad Request | Данный код можно увидеть, если запрос был сформирован с ошибками. Например, в нем отсутствовали символы завершения строки. |
| 403 Forbidden | Означает, что клиент не обладает достаточными правами доступа к запрошенному ресурсу. Также данный код можно встретить, если сервер обнаружил вредоносные данные, отправленные клиентом в запросе. |
| 404 Not Found | Каждый из нас, так или иначе, сталкивался с этим кодом ошибки. Данный код можно увидеть, если запросить у сервера ресурс, которого не существует на сервере. |
| 500 Internal Error | Данный код возвращается сервером, когда он не может по определенным причинам обработать запрос. |
Помимо основных кодов состояния, описанных в стандарте, существуют и коды состояния, которые объявляются крупными сетевыми провайдерами и серверными платформами. Так, коды состояния, используемые Selectel, можно посмотреть здесь.
Response Headers, или заголовки ответа, используются для того, чтобы уточнить ответ, и никак не влияют на содержимое тела. Они существуют в том же формате, что и остальные заголовки, а именно «Имя-Значение» с двоеточием (:) в качестве разделителя.
Ниже приведены наиболее часто встречаемые в ответах заголовки:
| Категория | Пример | Описание |
| Server | Server: ngnix | Содержит информацию о сервере, который обработал запрос. |
| Set-Cookie | Set-Cookie:PHPSSID=bf42938f | Содержит куки, требуемые для идентификации клиента. Браузер парсит куки и сохраняет их в своем хранилище для дальнейших запросов. |
| WWW-Authenticate | WWW-Authenticate: BASIC realm=»localhost» | Уведомляет клиента о типе аутентификации, который необходим для доступа к запрашиваемому ресурсу. |
Последней частью ответа является его тело. Несмотря на то, что у большинства ответов тело присутствует, оно не является обязательным. Например, у кодов «201 Created» или «204 No Content» тело отсутствует, так как достаточную информацию для ответа на запрос они передают в заголовке.
HTTP является расширяемым протоколом, который предоставляет огромное количество возможностей, а также поддерживает передачу всевозможных типов файлов. Однако, вне зависимости от версии, у него есть один существенный недостаток, который можно заметить если перехватить отправленный HTTP-запрос:
Да, все верно: данные передаются в открытом виде. HTTP сам по себе не предоставляет никаких средств шифрования.
Но как же тогда работают различные банковские приложения, интернет-магазины, сервисы оплаты услуг и прочие приложения, в которых циркулирует чувствительная информация пользователей?
Время рассказать про HTTPs!
HTTPs (HyperText Transfer Protocol, secure) является расширением HTTP-протокола, который позволяет шифровать отправляемые данные, перед тем как они попадут на транспортный уровень. Данный протокол по умолчанию использует порт 443.
Теперь если мы перехватим не HTTP , а HTTPs-запрос, то не увидим здесь ничего интересного:
Данные передаются в едином зашифрованном потоке, что делает невозможным получение учетных данных пользователей и прочей критической информации средствами обычного перехвата.
Три межсетевых экрана для любых потребностей бизнеса.
Выбрать
Если хотите подробнее узнать о деталях работы протокола, читайте статью в нашем блоге →
Теория это, конечно, отлично, но ничего так хорошо не закрепляет материал, как практика
Мы рассмотрим несколько способов, как написать HTTP-запрос в браузер, послать HTTP-запрос на сервер и получить ответ:
Основной программой на наших устройствах, которая работает с HTTP-протоколом, в большинстве случаев является браузер. Помимо обычных пользователей, с браузерами часто работают и разработчики веб-приложений. Именно их инструментами мы воспользуемся для работы с запросами и ответами.
По нажатию комбинации клавиш [Ctrl+Shift+I] или просто [F12] в подавляющем большинстве современных браузеров у нас откроется окно инструментов разработчика, которая представляет собой панель с несколькими вкладками.
Нужная нам вкладка обычно называется Network. Перейдем в нее, а в адресной строке введем URL того сайта, на который хотим попасть. В качестве примера воспользуемся сайтом блога Selectel — https://selectel.ru/blog/.
После нажатия Enter сайт начнет загружаться, а открытая вкладка Network — заполняться различными элементами, начиная все больше напоминать приборную панель самолета.
Не спешите пугаться. Это всего лишь список ресурсов, которые нужны для правильного отображения и работы сайта.
Нажав на любой из них, мы можем увидеть детали обработки отправленного запроса:
В данном запросе, например:
Следующий инструмент, с помощью которого мы сможем послать запрос на тот или иной сервер, это утилита cURL.
cURL (client URL) является небольшой утилитой командной строки, которая позволяет работать с HTTP и рядом других протоколов.
Для отправки запроса и получения ответа мы можем воспользоваться флагом -v и указанием URL того ресурса, который мы хотим получить. «Схему» HTTP-запроса можно увидеть на скрине ниже:
После запуска утилита выполняет:
Помимо этого, у данной утилиты есть огромное количество опций, которые предоставляют возможности по детальной настройке отправляемых запросов. Все эти возможности и делают ее такой популярной у веб-разработчиков и других специалистов, которым приходится работать с протоколом HTTP.
HTTP представляет собой расширяемый протокол прикладного уровня, на котором работает весь веб-сегмент интернета. В данной статье мы рассмотрели принцип его работы, структуру, «компоненты» HTTP-запросов.
Коснулись вопросов отличия версий протокола, HTTPs — его расширения, добавляющего шифрование. Разобрали устройство запроса, поняли, как можно отправить HTTP-запрос и получить ответ от сервера.
Основными или наиболее часто используемыми методами HTTP являются POST, GET, PUT, PATCH и DELETE. Эти методы соответствуют операциям создания, чтения, обновления и удаления (или CRUD) соответственно. Есть и другие методы, но они используются реже.
Ниже приведена таблица, в которой представлены HTTP-методы, доступные в Oro API, и их возвращаемые значения в сочетании с URI ресурсов:
| Метод HTTP | CRUD-операция | Вся коллекция (например, /users) | Конкретный элемент (например, /users/{id}) |
|---|---|---|---|
| ПОЛУЧИТЬ | Читать | 200 (ОК), список сущностей. Используйте пагинацию, сортировку и фильтрацию
для навигации по большим спискам. | 200 (ОК), одно целое. 404 (не найдено), если идентификатор не найден или недействителен. |
| ПОСТ | Создать | 201 (Создано), Ответ содержит ответ аналогичен GET /user/{id} содержащий новый идентификатор. | неприменимо |
| ЗАПЛАТКА | Обновление | Пакетный API | 200 (ОК) или 204 (Нет содержимого). 404 (не найдено), если идентификатор не найден или недействителен. |
| УДАЛИТЬ | Удалить | 204 (без содержимого). 400 (неверный запрос), если фильтр не указан. | 204 (без содержимого). 404 (не найдено), если идентификатор не найден или недействителен. |
| ПУТ | Обновить/Заменить | не реализовано | не реализовано |
Кроме того, методы HTTP можно классифицировать по свойствам идемпотента и безопасности .
Безопасные методы — это методы HTTP, которые не изменяют ресурсы. Например, используя GET или HEAD для URL-адреса ресурса, НИКОГДА не должен изменять ресурс.
Идемпотентный HTTP-метод — это HTTP-метод, который можно вызывать много раз без разных результатов. Это не было бы имеет значение, вызывается ли метод только один раз или десять раз. Результат должен быть таким же. Дополнительные сведения см. в документе RFC 7231: общие свойства методов.
Ниже приведена таблица, суммирующая методы HTTP по их идемпотентности и безопасности:
| Метод HTTP | Идемпотент | Сейф |
|---|---|---|
| ОПЦИИ | да | да |
| ПОЛУЧИТЬ | да | да |
| ГОЛОВКА | да | да |
| ПУТ | да | нет |
| ПОЧТ | нет | нет |
| УДАЛИТЬ | да | нет |
| ЗАПЛАТКА | нет | нет |
Деловой совет
Исследуете платформы электронной коммерции B2B? Изучите наше руководство по сравнению платформ, которое поможет вам принять обоснованное решение.
Метод HTTP GET используется для чтения (или извлечения) представления ресурса. В случае успеха (или отсутствия ошибки) GET возвращает представление в формате JSON и код состояния ответа HTTP 200 (ОК). В случае ошибки чаще всего возвращается 404 (НЕ НАЙДЕНО) или 400 (НЕПРАВИЛЬНЫЙ ЗАПРОС).
Примечание
В соответствии со спецификацией HTTP запросы GET используются только для чтения данных, но не для их изменения. Поэтому они считаются безопасными. То есть их можно вызывать без риска модификации или повреждения данных — однократный вызов имеет тот же эффект, что и 10-кратный вызов.
Метод POST чаще всего используется для создания новых ресурсов. В частности, он используется для создания подчиненных
Ресурсы. Это подчинено какому-то другому (например, родительскому) ресурсу. Другими словами, при создании нового ресурса
POST к родителю, и служба позаботится о том, чтобы связать новый ресурс с родителем, назначив
ID (новый URI ресурса) и т.
При успешном создании возвращается код ответа HTTP 201.
Осторожно
POST не является безопасной операцией. Выполнение двух одинаковых запросов POST, скорее всего, приведет к тому, что два ресурса будут содержать одинаковую информацию, но с разными идентификаторами.
Примечание
Можно создать как первичные, так и связанные ресурсы API с помощью одного запроса API. Подробнее см. Создание и обновление связанных ресурсов с помощью раздела «Основной ресурс API».
PATCH используется для модификации ресурсов. Запрос PATCH должен содержать только изменения в ресурсе, не полный ресурс.
Другими словами, тело должно содержать набор инструкций, описывающих, как ресурс, находящийся в данный момент на сервер должен быть изменен для создания новой версии.
Осторожно
ИСПРАВЛЕНИЕ — небезопасная операция. Коллизии от нескольких запросов PATCH могут быть опасными, поскольку некоторые форматы исправлений должны работать с известной базовой точкой; в противном случае они испортят ресурс.
Клиенты, использующие такой патч
приложение должно использовать условный запрос (например, ПОЛУЧИТЬ ресурс, убедиться, что он не был изменен, и применить ИСПРАВЛЕНИЕ), чтобы запрос не выполнялся, если ресурс был обновлен с момента последнего доступа клиента к ресурсу.
Примечание
Дополнительные сведения см. в разделе «Создание и обновление связанных ресурсов с основным ресурсом API».
УДАЛИТЬ довольно легко понять. Он используется для удаления ресурса, идентифицированного фильтрами или идентификатором.
При успешном удалении возвращается код состояния ответа HTTP 204 (без содержимого) без тела ответа.
Важно
Если вы УДАЛИТЕ ресурс, он будет удален. Многократный вызов DELETE для этого ресурса часто возвращает код состояния 404 (НЕ НАЙДЕН), поскольку он уже был удален и, следовательно, больше не может быть найден.
Метод HTTP ОПЦИИ запрашивает разрешенные параметры связи для данного URL-адреса или сервера.
* ) для ссылки на весь сервер.| Запрос имеет тело | № |
|---|---|
| Успешный ответ имеет тело | Да |
| Сейф | Да |
| Идемпотент | Да |
| Кэшируемый | № |
| Разрешено в формах HTML | № |
ВАРИАНТЫ /index.html HTTP/1.1 ВАРИАНТЫ * HTTP/1.1
Чтобы узнать, какие методы запросов поддерживает сервер, можно использовать программу командной строки curl для выполнения запроса OPTIONS :
curl -X ОПЦИИ https://example.org -i
Затем ответ содержит заголовок Allow , содержащий разрешенные методы:
HTTP/1.
В CORS предварительный запрос отправляется с помощью метода OPTIONS , чтобы сервер мог ответить, допустимо ли отправлять запрос. В этом примере мы запросим разрешение на следующие параметры:
1 204 Нет содержимого
Разрешить: OPTIONS, GET, HEAD, POST
Кэш-контроль: max-age=604800
Дата: Чт, 13 октября 2016 г., 11:45:00 по Гринвичу
Сервер: EOS (lax004/2813)
Access-Control-Request-Method , отправленный в предварительном запросе, сообщает серверу, что при отправке фактического запроса он будет иметь метод запроса POST . Access-Control-Request-Headers сообщает серверу, что при отправке фактического запроса он будет иметь заголовки X-PINGOTHER и Content-Type .ВАРИАНТЫ /resources/post-here/ HTTP/1.1 Хост: bar.example Принять: текст/html, приложение/xhtml+xml, приложение/xml; q=0,9,*/*;q=0,8 Accept-Language: en-us,en;q=0.
Теперь сервер может ответить, если он примет запрос при данных обстоятельствах. В этом примере ответ сервера говорит следующее:
5
Accept-Encoding: gzip, deflate
Соединение: Keep-alive
Происхождение: https://foo.example
Метод запроса-управления-доступом: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
Access-Control-Allow-Origin Источнику https://foo.example разрешено запрашивать bar.example/resources/post-here/ URL по следующему адресу:
Методы разрешения доступа POST , GET и OPTIONS являются разрешенными методами для URL-адреса. (Этот заголовок аналогичен заголовку ответа Allow , но используется только для CORS.)
X-PINGOTHER и Content-Type являются разрешенными заголовками запроса для URL.
Контроль доступа-Max-Age Указанные выше разрешения могут кэшироваться на 86 400 секунд (1 день).