структура - Как параметры отправляются в HTTP-запрос POST?




структура http запроса (6)

В запросе HTTP GET параметры отправляются как строка запроса :

http://example.com/page?parameter=value&also=another

В запросе HTTP POST параметры не отправляются вместе с URI.

Где значения? В заголовке запроса? В теле запроса? На что это похоже?


Вы не можете вводить его непосредственно в строке URL браузера.

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

http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1

Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password

Где он говорит

Content-Length: 30
    username=zurfyx&pass=password

будут значения post.


Значения отправляются в тело запроса в том формате, который указан в типе содержимого.

Обычно тип содержимого - application/x-www-form-urlencoded , поэтому тело запроса использует тот же формат, что и строка запроса:

parameter=value&also=another

Когда вы используете загрузку файла в форме, вместо этого вы используете кодировку multipart/form-data , которая имеет другой формат. Это сложнее, но вам обычно не нужно заботиться о том, как это выглядит, поэтому я не буду показывать пример, но может быть полезно знать, что он существует.


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

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

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

Этот подход логически объединяет QueryString и Body-Post с использованием одного Content-Type который является «инструкцией по синтаксическому разбору» для веб-сервера.

Обратите внимание: HTTP / 1.1 завернута в #32 (пробел) слева и с #10 (Line feed) справа.


Прежде всего, давайте GET и POST

Получить: Это HTTP запрос по умолчанию, который делается на сервере, и используется для извлечения данных с сервера и строки запроса, которая появляется после ? в URI используется для извлечения уникального ресурса.

это формат

GET /someweb.asp?data=value HTTP/1.0

здесь data=value - переданное значение строки запроса.

POST: он используется для безопасного отправления данных на сервер, чтобы все, что необходимо, это формат запроса POST

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

Почему POST над GET?

В GET значение, отправляемое на серверы, обычно добавляется к базовому URL-адресу в строке запроса. Это позволяет взломать ваши данные (это было проблемой в дни для Facebook, где были установлены ваши учетные данные), поэтому POST используемый для отправки данных на сервер, который использовал Request Body для отправки ваших данных на сервер, который более безопасен, поскольку он скрывает ваши данные, и он получает ваши данные из полей, вычисляет их длину и добавляет их в header для content-length и никакие важные данные напрямую не добавляются к URL

теперь, когда ваш запрос защищен, любые значения, отправляемые на сервер, могут быть отправлены в Request Body поскольку имя подразумевает, что оно будет содержать пользователей данных, которые хотели бы отправить (и Он отправляется в URL Encoded формате URL Encoded ), а Request Headers будут сохраняйте запрос безопасным путем сравнения значений в Request Body с Request Headers

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

и вы всегда можете добавить больше значений в Request Headers такие как Cache-Control , Origin , Accept .


Тип носителя по умолчанию в POST-запросе - application/x-www-form-urlencoded . Это формат для кодирования пар ключ-значение. Ключи могут быть дублированы. Каждая пара ключ-значение разделяется символом & , и каждый ключ отделяется от его значения символом = .

Например:

Name: John Smith
Grade: 19

Записывается как:

Name=John+Smith&Grade=19

Он помещается в тело запроса после заголовков HTTP.


Короткий ответ: в POST-запросах значения отправляются в «тело» запроса. В веб-формах они, скорее всего, отправляются с медиа-типом application/x-www-form-urlencoded или multipart/form-data . Языки программирования или фреймворки, предназначенные для обработки веб-запросов, обычно выполняют «The Right Thing ™» с такими запросами и обеспечивают вам легкий доступ к легко декодированным значениям (например, $_REQUEST или $_POST в PHP или cgi.FieldStorage() , flask.request.form в Python).

Теперь давайте немного отвлечемся, что может помочь понять разницу;)

Разница между запросами GET и POST в значительной степени семантична. Они также «используются» по-разному, что объясняет разницу в том, как передаются значения.

GET ( соответствующий раздел RFC )

При выполнении запроса GET вы запрашиваете сервер для одного или набор объектов. Чтобы клиент мог фильтровать результат, он может использовать так называемую «строку запроса» URL-адреса. Строка запроса является частью после ? , Это часть синтаксиса URI .

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

Обратите внимание, что ключи и значения являются частью URI. Браузеры могут налагать ограничение на длину URI. В стандарте HTTP указано, что ограничений нет. Но на момент написания этой статьи большинство браузеров ограничивают URI (у меня нет конкретных значений). Запросы GET никогда не должны использоваться для отправки новой информации на сервер. Особенно не крупные документы. Здесь вы должны использовать POST или PUT .

POST ( соответствующий раздел RFC )

При выполнении запроса POST клиент фактически отправляет новый документ удаленному хосту. Таким образом, строка запроса не (семантически) имеет смысл. Вот почему у вас нет доступа к ним в вашем коде приложения.

POST немного сложнее (и более гибким):

При получении запроса POST вы всегда должны ожидать «полезную нагрузку», или в терминах HTTP: тело сообщения . Тело сообщения само по себе довольно бесполезно, поскольку нет стандартного (насколько я могу судить. Может быть, application / octet-stream?) Формата. Формат тела определяется заголовком Content-Type . При использовании элемента HTML FORM с method="POST" это обычно application/x-www-form-urlencoded . Другим очень распространенным типом является multipart/form-data если вы используете загрузку файлов. Но может быть что угодно : от text/plain , над application/json или даже с настраиваемым application/octet-stream .

В любом случае, если запрос POST выполняется с Content-Type который не может быть обработан приложением, он должен вернуть код состояния 415 .

Большинство языков программирования (и / или веб-фреймворки) предлагают способ де-кодирования тела сообщения от / до наиболее распространенных типов (например, application/x-www-form-urlencoded , multipart/form-data или application/json ) , Так что это легко. Пользовательские типы требуют потенциально немного больше работы.

Используя пример стандартного HTML-кодированного документа, приложение должно выполнить следующие шаги:

  1. Прочитайте поле Content-Type
  2. Если значение не является одним из поддерживаемых типов носителей, тогда возвращайте ответ с кодом статуса 415
  3. в противном случае, декодировать значения из тела сообщения.

Опять же, такие языки, как PHP, или веб-фреймворки для других популярных языков, вероятно, справятся с этим для вас. Исключением является ошибка 415 . Никакая структура не может предсказать, какие типы контента ваше приложение выбирает для поддержки и / или не поддержки. Это зависит от вас.

PUT ( соответствующий раздел RFC )

Запрос PUT обрабатывается точно так же, как запрос POST . Большая разница заключается в том, что запрос POST должен позволить серверу решить, как (и если вообще) создать новый ресурс. Исторически (из теперь устаревшего RFC2616 он должен был создать новый ресурс как «подчиненный» (дочерний) URI, куда был отправлен запрос).

Предполагается, что запрос PUT должен «откладывать» ресурс именно в этом URI и именно с этим контентом. Не больше, не меньше. Идея заключается в том, что клиент несет ответственность за создание полного ресурса до «PUTting». Сервер должен принять его как есть на данном URL-адресе.

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

Примечание

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

Помимо точечных сегментов в иерархических путях, сегмент пути считается непрозрачным по обобщенному синтаксису. В URI, создающих приложения, часто используются зарезервированные символы, разрешенные в сегменте, для разграничения подкомпонентов, специфичных для конкретной схемы или разнесения. Например, зарезервированные символы с запятой (";") и равно ("=") часто используются для разграничения параметров и значений параметров, применимых к этому сегменту. Зарезервированный символ запятой (",") часто используется для аналогичных целей. Например, один производитель URI может использовать сегмент, такой как «name; v = 1.1», чтобы указать ссылку на версию 1.1 «name», тогда как другой может использовать сегмент, такой как «name, 1.1», чтобы указать его. Типы параметров могут быть определены с помощью специфичной для схемы семантики, но в большинстве случаев синтаксис параметра специфичен для реализации алгоритма разыменования URI.





uri