Главная » Фишки с ПК » Типы HTTP-запросов и философия REST. Схема функционирования HTTP-сообщений и возможные риски Пример между PUT и PATCH

Типы HTTP-запросов и философия REST. Схема функционирования HTTP-сообщений и возможные риски Пример между PUT и PATCH

7 ответов

СООБЩЕНИЕ

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

ПОЛОЖИЛ

HTTP.PUT может использоваться, когда клиент отправляет данные на сервер, и клиент определяет URI для вновь созданного ресурса. Метод PUT запрашивает, чтобы вложенный объект был сохранен под предоставленным Request-URI. Если Request-URI ссылается на уже существующий ресурс, вложенный объект СЛЕДУЕТ рассматривать как модифицированную версию, находящуюся на исходном сервере. Если Request-URI не указывает на существующий ресурс, и этот URI может быть определен как новый ресурс запрашивающим пользовательским агентом, сервер-источник может создать ресурс с этим URI.

PATCH

HTTP.PATCH может использоваться, когда клиент отправляет одно или несколько изменений, которые будут применены сервером. Метод PATCH запрашивает, чтобы набор изменений, описанный в объекте запроса, был применен к ресурсу, идентифицированному Request-URI. Набор изменений представлен в формате, называемом патч-документ.

Для получения дополнительной информации обратитесь к указанному ниже URL

Разница между PUT, POST, GET, DELETE и PATCH IN HTTP Глаголы:

Наиболее часто используемые HTTP-глаголы POST, GET, PUT, DELETE аналогичны операциям CRUD (Create, Read, Update and Delete) в базе данных. Мы указываем эти HTTP-глаголы в случае с капиталом . Итак, ниже показано сравнение между ними.

  1. create - POST
  2. читать - GET
  3. update - PUT
  4. delete - DELETE

PATCH: Предоставляет частичную модификацию ресурса. Если вам нужно обновить только одно поле для ресурса, вы можете использовать метод PATCH.

Замечания:
Поскольку POST, PUT, DELETE изменяет содержимое, тесты с помощью скрипача для приведенного ниже URL просто подражают обновлениям. Он не удаляет и не изменяет фактически. Мы можем просто просмотреть коды состояния, чтобы проверить, не возникают ли вставки, обновления, удаления.

1) ПОЛУЧИТЬ:

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

Ответ: вы получите ответ как:

"userId": 1, "id": 1, "title": "sunt aut...", "body": "quia et suscipit..."

В пути "счастливый" (или без ошибок) GET возвращает представление в XML или JSON и код ответа HTTP 200 (OK). В случае ошибки он чаще всего возвращает 404 (NOT FOUND) или 400 (BAD REQUEST).

2) POST:

Глагол POST в основном используется для создания новых ресурсов. В частности, он использовал для создания подчиненных ресурсов. То есть подчиняется другому (например, родительскому) ресурсу.

При успешном создании возвращайте HTTP-статус 201, возвращая заголовок Location с ссылкой на вновь созданный ресурс с HTTP-статусом 201.

Проверка с помощью Fiddler или PostMan: мы можем использовать скрипач для проверки ответа. Откройте скрипт и выберите вкладку Compose. Укажите глагол и URL-адрес, как показано ниже, и нажмите "Выполнить", чтобы проверить ответ.

Тело запроса:

данные: {title: "foo", body: "bar", userId: 1000, Id: 1000}

Ответ. Вы получите код ответа 201.

Если мы хотим проверить вставленную запись с Id = 1000, измените глагол Get и используйте тот же url и нажмите Execute.

Как было сказано ранее, указанный выше URL-адрес позволяет читать только чтения (GET), мы не можем читать обновленные данные в реальном времени.

PUT чаще всего используется для возможностей обновления , PUT-ing к известному URI ресурса с телом запроса, содержащим обновленное представление исходного ресурса.

Проверка с помощью Fiddler или PostMan: мы можем использовать скрипач для проверки ответа. Откройте скрипт и выберите вкладку Compose. Укажите глагол и URL-адрес, как показано ниже, и нажмите "Выполнить", чтобы проверить ответ.

Тело запроса:

data: {title: "foo", body: "bar", userId: 1, Id: 1}

Ответ. При успешном обновлении он возвращает 200 (или 204, если не возвращает какой-либо контент в теле) из PUT.

4) УДАЛИТЬ:

DELETE довольно легко понять. Он используется для удаления ресурса, идентифицированного с помощью URI.

При успешном удалении возвращайте HTTP-статус 200 (OK) вместе с телом ответа, возможно, представление удаленного элемента (часто требует слишком большой полосы пропускания) или завернутый ответ (см. "Возвращаемые значения" ниже). Либо это, либо вернуть статус HTTP 204 (NO CONTENT) без тела ответа. Другими словами, рекомендуемый ответ - статус 204 без тела, или ответ типа JSEND и статус HTTP 200.

Проверка с помощью Fiddler или PostMan: мы можем использовать скрипач для проверки ответа. Откройте скрипт и выберите вкладку Compose. Укажите глагол и URL-адрес, как показано ниже, и нажмите "Выполнить", чтобы проверить ответ.

Глагол: УДАЛИТЬ

Ответ. При успешном удалении он возвращает статус HTTP 200 (OK) вместе с телом ответа.

Пример между PUT и PATCH

ПОЛОЖИЛ

Если мне пришлось изменить свое имя, то отправьте запрос PUT для обновления:

{"first": "Nazmul", "last": "hasan"} Итак, здесь, чтобы обновить первое имя, нам нужно снова отправить все параметры данных.

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

Для получения дополнительной информации см. Ссылки ниже:

PUT = заменить ПОЛНЫЙ РЕСУРС новым представлением

PATCH = заменить части исходного ресурса на значения, предоставленные И | ИЛИ другие части ресурса обновлены, которые вы предоставили (временные метки) И | ИЛИ обновили ресурсные эффекты другими ресурсами (отношениями)

GET/PUT - идемпотентный патч иногда может быть идемпотентным

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

get: -

просто получить. Получить данные с сервера и показать их пользователю

post: -

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

put: -

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

{ id:1 name:parth email:[email protected] }

{ id:1 email:[email protected] }

patch

так что теперь пришел патч, запрос PATCH может быть иногда идемпотентным

Id:1 name:parth email:[email protected] }

Название патча: W

{ id:1 name:w email:[email protected] } HTTP Method GET yes POST no PUT yes PATCH no* OPTIONS yes HEAD yes DELETE yes

Приведенное ниже определение взято из примера из реального мира.

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

  1. СООБЩЕНИЕ

    • Если Клиент отправляет данные без идентификатора с использованием метода POST, мы сохраняем их и назначаем новый идентификатор.
    • Если Клиент снова отправляет те же данные без идентификатора с помощью метода POST, мы сохраняем их и назначаем новый идентификатор.
    • Примечание : дублирование разрешено здесь

  2. ПОЛОЖИЛ

    • Если Клиент отправляет данные с идентификатором, мы проверим, существует ли этот идентификатор. Если идентификатор существует, мы обновим данные, в противном случае мы создадим его и назначим новый идентификатор.
    • Если Клиент отправляет данные с идентификатором, мы проверим, существует ли этот идентификатор. Если идентификатор существует, мы обновим данные, иначе мы сгенерируем исключение.

Примечание. В методе Put мы не генерируем исключение, если идентификатор не найден. Но в методе Patch мы генерируем исключение, если идентификатор не найден.

Дайте мне знать, если у вас есть какие-либо вопросы по вышеуказанному.

Вот разница между методами POST, PUT и PATCH протокола HTTP.

POST

Метод HTTP.POST всегда создает новый ресурс на сервере. Его не-идемпотентный запрос, т.е. Если пользователь обращается к тем же запросам 2 раза, он создаст новый новый ресурс, если нет ограничений.

http post method is like a INSERT query in SQL which always creates a new record in database.

Пример. Используйте метод POST для сохранения нового пользователя, заказа и т.д., когда серверный сервер решает идентификатор ресурса для нового ресурса.

PUT

В методе HTTP.PUT ресурс сначала идентифицируется из URL-адреса, и если он существует, то он обновляется, иначе создается новый ресурс. Когда целевой ресурс существует, он перезаписывает этот ресурс с полным новым телом. Это метод HTTP.PUT используется для СОЗДАНИЯ или ОБНОВЛЕНИЯ ресурса.

http put method is like a MERGE query in SQL which inserts or updates a record depending upon whether the given record exists.

Запрос PUT является idempotent, т.е. удары одних и тех же запросов дважды будут обновлять существующую запись (новая запись не создается). В методе PUT идентификатор ресурса определяется клиентом и указан в URL-адресе запроса.

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

PATCH

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

http patch method is like a UPDATE query in SQL which sets or updates selected columns only and not the whole row.

Пример. Вы можете использовать метод PATCH для обновления состояния заказа.

PATCH/api/users/40450236/order/10234557

PHP provides support for the HTTP PUT method used by some clients to store files on a server. PUT requests are much simpler than a file upload using POST requests and they look something like this:

PUT /path/filename.html HTTP/1.1

This would normally mean that the remote client would like to save the content that follows as: /path/filename.html in your web tree. It is obviously not a good idea for Apache or PHP to automatically let everybody overwrite any files in your web tree. So, to handle such a request you have to first tell your web server that you want a certain PHP script to handle the request. In Apache you do this with the Script directive. It can be placed almost anywhere in your Apache configuration file. A common place is inside a block or perhaps inside a block. A line like this would do the trick:

Script PUT /put.php

This tells Apache to send all PUT requests for URIs that match the context in which you put this line to the put.php script. This assumes, of course, that you have PHP enabled for the .php extension and PHP is active. The destination resource for all PUT requests to this script has to be the script itself, not a filename the uploaded file should have.

With PHP you would then do something like the following in your put.php. This would copy the contents of the uploaded file to the file myputfile.ext on the server. You would probably want to perform some checks and/or authenticate the user before performing this file copy.

Example #1 Saving HTTP PUT files

/* PUT data comes in on the stdin stream */
$putdata = fopen ("php://input" , "r" );

/* Open a file for writing */
$fp = fopen ("myputfile.ext" , "w" );

/* Read the data 1 KB at a time
and write to the file */
while ($data = fread ($putdata , 1024 ))
fwrite ($fp , $data );

/* Close the streams */
fclose ($fp );
fclose ($putdata );
?>

13 years ago

A Case Study: To set up publishing with Netscape 7.2 Composer to Apache/PHP, no need to use CGI (which I tried unsuccessfully for too long) or to alter Apache"s httpd.conf. I needed only to click Publish As, fill in put2disk.php as the filename (where its contents are the below), and fill in that file"s dir as the "Publishing address".
XAMPP 1.4.14: Apache/2.0.54 (Win32) mod_ssl/2.0.54 OpenSSL/0.9.7g PHP/5.0.4.

//file_put_contents ("get_def.out", print_r (get_defined_vars(), TRUE)); // debugging

// Two slurp methods: (a) didn"t work, (b) did.
//$stdin_rsc = fopen("php://input", "r");
//$putdata="";
//while ($putdata .= fread($stdin_rsc, 1024)); // a. Hangs the "Publishing..." dialog.
//while (!feof($stdin_rsc)) $putdata.=fread($stdin_rsc, 8192); // b. Worked, but file_get_contents is faster.
//fclose($stdin_rsc);

// All that"s nec:
$putdata=file_get_contents("php://input"); // Not php://stdin! (When the ability to see error messages isn"t available, the doc (this manual page) needs to be more accurate.)

file_put_contents("stdin.out",$putdata);
?>

В этой статье мы рассмотрим структуру 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.

612

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 (перемещенный постоянный) ответ; пользовательский агент МОЖЕТ затем сделать своим собственным решением относительно того, перенаправить запрос или нет.

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

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

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

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

Там также удобный пункт, чтобы объяснить разницу между 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.

9

Это кажется бесполезным грубым и педантичным менее полезным способом. В примере PUT, который вы цитируете, новый объект в RESTful api является «новой» записью и доступен в этом месте. Не вызывает сомнений, является ли хороший выбор дизайна, позволяющий подменям быть такими, как это (я думаю, что это не идеальный вариант), но даже если бы вы использовали подвид, чтобы нападать на большую полезную информацию. В большинстве случаев описание, как обычно говорится, является отличным заявлением о содержании RFC, суммированном и заявлении обычной и обычной практики. Кроме того, вам не будет больно быть вежливым. - tooluser 06 апр. 15 2015-04-06 23:49:56

60

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

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

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

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

5) УДАЛИТЬ: - Используется, когда клиент пытается удалить документ с веб-сервера, идентифицированный URL-адресом запроса.

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

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

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

15

  • УДАЛЕНИЕ: Удаляет данные с сервера.
  • TRACE: Предоставляет способ проверить, какой сервер получает. Он просто возвращает то, что было отправлено.
  • ОПЦИИ: Позволяет клиенту получать информацию о методах запросов, поддерживаемых службой. Соответствующим заголовком ответа является «Разрешить» с поддерживаемыми методами. Также используется в CORS в качестве предполетного запроса информировать сервер о фактическом методе запроса и спрашивать о пользовательских заголовках.
  • HEAD: возвращает только заголовки ответов.
  • CONNECT: Используется браузером, когда он знает, что он говорит с прокси, и окончательный URI начинается с https: //. Цель CONNECT состоит в том, чтобы разрешить сквозной зашифрованный сеанс TLS, поэтому данные нечитабельны для прокси.

    • 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. Во второй части будет ещё больше интересных фактов и примеров.

    Поделиться:

    Похожие статьи