GET или POST? — вот в чем вопрос!
В последнее время в сложившейся практике разработки сайтов наибольшую популярность получили два типа HTTP запросов: GET и POST. Казалось бы ничего сложного в этих двух понятиях нет, но начинающие и неопытные веб-разработчики очень часто допускают непростительные ошибки при выборе определенного метода. Главным образом это происходит по той причине, что эти 2 разные пути могут привести к одному и тому же результату. Ценой неправильного выбора типа запроса может быть угроза безопасности ресурса или информационная перегрузка сервера.
Итак, чтобы не допускать принятие неправильных решений, следует подробнее разобрать суть обоих методов. Это позволит докопаться до истины и вывести веб-разработчика на верный путь.
Очень действенный метод восприятия информации — это ассоциативное мышление, поэтому предлагаю придумать для каждого понятия ассоциацию и связывать функциональные возможности с этим предметом. Обратимся к названиям методов, а точнее к их переводу на русский язык. К примеру, GET переводится, как получать, другими словами получить запрос. А вот POST можно трактовать, пересылка письма по почте. Для программиста это значит, что такой метод будет связан с передачей информации на сервер. Это тот необходимый минимум, который научит новичка не путаться в этих понятиях. Однако, если простые лендинги с формой отправки данных — это для Вас не предел, тогда подойдем в плотную к этому вопросу.
Безопасные и небезопасные HTTP запросы
Изучив спецификацию HTTP 1.1, можно констатировать тот факт, что классификация разновидностей методов запросов насчитывает два типа: безопасный и небезопасный запрос.
Теперь стоит разъяснить суть каждого из методов. Безопасными называются те запросы, которые не имеют никакого влияния на ресурс, они просто запрашивают и помогают считывать информацию. Примером такого запроса является отображение картинки — через ее адрес идет запрос на сервер в указанную директиву, где должен находится файл с картинкой. Такой тип запроса распространяется на методы HEAD и GET.
На заметку
Безопасный метод — это еще не гарантия отсутствия проблем. Ущерб может нанести зацикливание определенного типа запроса, даже если он и безопасный.
Теперь обратимся к понятию небезопасного запроса. Такой метод предусматривает внесение изменений определенным данным на сайте. Наиболее вероятные проблемы возникают в том случае, когда запрос осуществляется повторно или без надобности. В качестве примера следует отметить такие процессы, как онлайн-регистрация, пересылание сообщения или веб-платежи. Пот такой тип запроса относят POST, PUT и DELETE методы.
Идемпотентные методы
Это сложное для восприятия и произношения понятие означает способность некоторых из методов предоставлять одни и те же данные при многочисленных запросах. Та ситуация, когда информация была обновлена, во внимание не берется. Изъясняясь более понятно, это тот случай, когда при запросе файла по одному и тому же адресу будет выводиться постоянно одна и та же информация (например, картинка). Такая способность присуща GET, PUT, DELETE методам.
Узнав более подробнее про типы и методы запросов, возвращаемся к нашему главному вопросу — GET и POST. Разберем все характерные черты этих понятий, которые описывают принципиальные отличия одного от другого.
- нужен для получения информации с сервера и не влияет на его содержимое;
- в теле запроса отсутствуют какие-либо элементы;
- для обработки на сервере не требует много времени или вспомогательных ресурсов;
- переменные проходят через адресную строку, что визуально доступно для пользователя, и в результате чего данные не имеют никакой защиты;
- существует предел объема информации для передачи. Ограничения выставляются главным образом браузерами. К примеру, IE шестой версии не позволяет использовать адрес, объем которого превышает 2 килобайта;
- используется единая система кодировки данных — система ASCII;
- вышеуказанная кодировка позволяет копировать свое содержимое или сохранять;
- запрос доступен для кеширования данных;
- существуют такие понятия, как условные и частичные запросы, посредством которых уменьшается нагрузка на информационный канал;
- работает по непрерывной связи HTTP (соответствует режиму keepAlive на сервере).
- целью использования такого запроса является отправка данных, что может оказывать влияние на содержимое ресурса;
- тело запроса не является пустым, в нем размещены данные, которые нужно отправлять;
- проигрывает в скорости энергоемкости обработки запроса методу GET, так как тело запроса несет в себе основную информацию;
- имеет возможность нести в себе большой объем информации, откуда следует, что не исключается возможность передачи файлов на сервер;
- такая страница не может быть скопирована или сохранена;
- имеет способность разрывать соединение HTTP;
- процедура передачи информации для сервера осуществляется посредством двух пакетов TCP, в одном из которых содержится заголовок, а в другом — тело с информацией.
На этом будем завершать анализ методов. Теперь вы можете убедиться в том, что не совсем POST похож на GET. Поэтому при выборе метода в первую очередь следует проанализировать поставленные цели для ресурса, а затем, исходя из принятых решений, делать выбор. Да, стоит отметить, что по умолчанию работает метод GET.
Для удобности привожу шпаргалку, которая в большинстве случаев направит разработчика на верный путь и позволит принять верное решение:
- запрос попадает под классификацию небезопасного — POST;
- если нельзя оперировать свойством идемпотентности — POST;
- не получится избежать передачи большого количества информации — POST;
- для всех остальных случаев применяем GET в силу его быстродействия, экономичности ресурсов и простоте использования.
Хоть и шпаргалка не сможет помочь в специфических и сложных ситуациях, но для решения стандартных задач будет неоценимым помощником.
What is the difference between a HTTP-Get and HTTP-POST and why is HTTP-POST weaker in terms of security
Can anyone explain the difference between a HTTP-GET and HTTP-POST? And why do people say that a HTTP-POST is weaker in terms of security?
5 Answers 5
In an HTTP GET request, key/value pairs are specified in the URL:
In an HTTP POST request, key/value pairs are sent as part of the HTTP request after the headers. For example:
It’s hard to really describe one as being more or less secure than the other, but HTTP POST data is not visible in the URL, and when submitting data to a website, an HTTP POST can usually only be performed as a result of user interaction (for example clicking on a «Submit» button).
This means a user can’t be tricked into visiting a URL like http://server/update_profile?name=I_suck and sensitive data is not exposed in the URL.
You can also use nonces and other anti-forgery tokens with html forms (which use POST) to prevent other forms of cross-site request forgeries.
In general, POST should be used for requests that potentially modify state on the server, and GET should be used for read-only operations.
Web Security: введение в HTTP
HTTP — вещь прекрасная: протокол, который просуществовал более 20 лет без особых изменений.
Это вторая часть серии по веб-безопасности: первая часть была «Как работают браузеры».
Как мы видели в предыдущей статье, браузеры взаимодействуют с веб-приложениями по протоколу HTTP, и это главная причина, по которой мы углубляемся в эту тему. Если пользователи введут данные своей кредитной карты на веб-сайте, а злоумышленник сможет перехватить данные до того, как они попадут на сервер, у нас наверняка будут проблемы.
Понимание того, как работает HTTP, как мы можем защитить связь между клиентами и серверами и какие функции, связанные с безопасностью, предлагает протокол, является первым шагом на пути к улучшению нашей безопасности.
При обсуждении HTTP, тем не менее, мы всегда должны различать семантику и техническую реализацию, поскольку это два совершенно разных аспекта работы HTTP.
Ключевое различие между ними можно объяснить очень простой аналогией: 20 лет назад люди заботились о своих родственниках так же, как и сейчас, даже при том, что способ их взаимодействия существенно изменился. Наши родители, вероятно, возьмут свою машину и поедут к сестре, чтобы наверстать упущенное и провести некоторое время вместе с семьей.
Вместо этого в наши дни чаще всего отправляют сообщения в WhatsApp, звонят по телефону или используют группу в Facebook, что раньше было невозможно. Это не значит, что люди общаются или заботятся больше или меньше, а просто то, что их взаимодействие изменилось.
HTTP ничем не отличается: семантика протокола не сильно изменилась, в то время как техническая реализация взаимодействия клиентов и серверов с годами была оптимизирована. Если вы посмотрите на HTTP-запрос 1996 года, он будет очень похож на те, что мы видели в предыдущей статье, хотя способ прохождения этих пакетов через сеть сильно отличается.
Обзор
Как мы уже видели, HTTP следует модели запроса/ответа, когда клиент, подключенный к серверу, отправляет запрос, а сервер отвечает на него.
HTTP-сообщение (запрос или ответ) состоит из нескольких частей:
- «first line» (первая строка)
- headers (заголовки запроса)
- body (тело запроса)
GET /players/lebron-james HTTP/1.1
В этом случае клиент пытается получить ресурс ( GET ) по адресу /Players/Lebron-James через версию протокола 1.1 — ничего сложного для понимания.
После первой строки HTTP позволяет нам добавлять метаданные к сообщению через заголовки, которые принимают форму ключ-значение, разделенных двоеточием:
GET /players/lebron-james HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000
Например, в этом запросе клиент добавил к запросу 3 дополнительных заголовка: Host , Accept и Coolness .
Заголовки не должны использовать определенные, зарезервированные имена, но обычно рекомендуется полагаться на те, которые стандартизированы в спецификации HTTP: чем больше вы отклоняетесь от стандартов, тем меньше вас поймет другой участник обмена.
Cache-Control — это, например, заголовок, используемый для определения того, является ли (и каким образом) ответ кешируемым: большинство прокси и обратных прокси понимают его, следуя спецификации HTTP до буквы. Если бы вам пришлось переименовать заголовок Cache-Control в Awesome-Cache-Control , прокси не имели бы представления о том, как кэшировать ответ, так как они не созданы для соответствия спецификации, которую вы только что придумали.
Однако иногда имеет смысл включить в сообщение «пользовательский» заголовок, так как вы можете добавить метаданные, которые на самом деле не являются частью спецификации HTTP: сервер может решить включить техническую информацию в свой ответ, чтобы клиент мог одновременно выполнять запросы и получать важную информацию о состоянии сервера, который возвращает ответ:
.
X-Cpu-Usage: 40%
X-Memory-Available: 1%
.
При использовании пользовательских заголовков всегда предпочтительно ставить перед ними префикс с ключом, чтобы они не конфликтовали с другими заголовками, которые могут стать стандартом в будущем: исторически это работало хорошо, пока все не начали использовать «нестандартные» префиксы X что, в свою очередь, стало нормой. Заголовки X-Forwarded-For и X-Forwarded-Proto являются примерами пользовательских заголовков, которые широко используются и понимаются балансировщиками нагрузки и прокси-серверами, даже если они не являются частью стандарта HTTP.
Если вам нужно добавить собственный настраиваемый заголовок, в настоящее время обычно лучше использовать фирменный префикс, такой как Acme-Custom-Header или A-Custom-Header .
После заголовков запрос может содержать тело, которое отделено от заголовков пустой строкой:
POST /players/lebron-james/comments HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000
Best Player Ever
Наш запрос завершен: первая строка (информация о местоположении и протоколе), заголовки и тело. Обратите внимание, что тело является полностью необязательным и, в большинстве случаев, оно используется только тогда, когда мы хотим отправить данные на сервер, поэтому в приведенном выше примере используется метод POST .
Ответ сильно не имеет различий:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=3600
Первая информация, которая присылается в ответе, — это версия протокола, которую он использует, вместе со статусом этого ответа. Далее следуют заголовки и, если требуется, разрыв строки, за которым следует тело.
Как уже упоминалось, протокол подвергся многочисленным пересмотрам и со временем добавились новые функции (новые заголовки, коды состояния и т. д.), Но основная структура не сильно изменилась (первая строка, заголовки и тело). Что действительно изменилось, так это то, как клиенты и серверы обмениваются этими сообщениями — давайте рассмотрим это подробнее.
HTTP vs HTTPS vs H2
В HTTP произошли 2 значительных семантических изменения: HTTP / 1.0 и HTTP / 1.1.
«Где HTTPS и HTTP2?», Спросите вы.
HTTPS и HTTP2 (сокращенно H2) — это больше технических изменений, поскольку они представили новые способы доставки сообщений через Интернет, без существенного влияния на семантику протокола.
HTTPS является «безопасным» расширением HTTP и включает установление общего секретного ключа между клиентом и сервером, гарантируя, что мы общаемся с нужной стороной, и шифруем сообщения, которые обмениваются общим секретным ключом (подробнее об этом позже). Пока HTTPS был нацелен на повышение безопасности протокола HTTP, H2 был нацелен на обеспечение высокой скорости.
H2 использует двоичные, а не текстовые сообщения, поддерживает мультиплексирование, использует алгоритм HPACK для сжатия заголовков…… Короче говоря, H2 повышает производительность по HTTP/1.1.
Владельцы веб-сайтов неохотно переходили на HTTPS, так как это включало дополнительные обходы между клиентом и сервером (как уже упоминалось, необходимо установить общий секретный ключ между двумя сторонами), тем самым замедляя работу пользователя: с H2, который шифруется по умолчанию оправданий больше нет, так как такие функции, как мультиплексирование и server push, делают его лучше, чем простой HTTP/1.1.
HTTPS
HTTPS (HTTP Secure) позволяет клиентам и серверам безопасно общаться через TLS (Transport Layer Security), преемник SSL (Secure Socket Layer).
Проблема, на которую ориентирован TLS, довольно проста и может быть проиллюстрирована одной простой метафорой: ваша вторая половинка звонит вам в середине дня, когда вы находитесь на собрании, и просит вас сообщить им пароль учетной записи вашего онлайн-банкинга, поскольку она должна выполнить банковский перевод, чтобы обеспечить своевременную оплату за обучение вашего сына. Очень важно, чтобы вы сообщили об этом прямо сейчас, иначе вы столкнетесь с вероятностью того, что вашего ребенка отчислят из школы на следующее утро.
Теперь вы столкнулись с двумя проблемами:
- аутентификация (authentication) того, что вы действительно разговариваете со своей второй половинкой, поскольку это может быть кто-то, притворяющийся ей
- шифрование (encryption): передача пароля так, чтобы ваши коллеги не смогли его понять и записать
Чтобы проверить, с кем вы разговариваете, HTTPS использует Public Key Certificates(сертификаты открытых ключей), которые представляют собой не что иное, как сертификаты, указывающие личность конкретного сервера: когда вы подключаетесь через HTTPS к IP-адресу, сервер за этим адресом представляет вам его сертификат для вас, чтобы подтвердить свою личность. Возвращаясь к нашей аналогии, вы можете просто попросить свою вторую половинку сказать ваш номер социального страхования. Как только вы убедитесь, что номер правильный, вы получаете дополнительный уровень доверия.
Это, однако, не мешает «злоумышленникам» узнать номер социального страхования жертвы, украсть смартфон вашей второй половинки и позвонить вам. Как мы проверим личность звонящего?
Вместо того, чтобы прямо попросить свою вторую половинку написать свой номер социального страхования, вместо этого вы звоните своей маме (которая живет по соседству) и просите ее пойти в вашу квартиру и удостовериться, что именно ваша вторая половина говорит номер социального страхования. Это добавляет дополнительный уровень доверия, так как вы не считаете свою маму угрозой и полагаетесь на нее для проверки личности звонящего.
В терминах HTTPS ваша мама называется CA, сокращение от Certificate Authority: работа CA заключается в проверке личности конкретного сервера и выдаче сертификата с собственной цифровой подписью: это означает, что при подключении к определенному домену я получу не сертификат, сгенерированный владельцем домена (так называемый самоподписанный сертификат), а CA.
Задача CA состоит в том, что они проверяют подлинность домена и выдают сертификат соответствующим образом: когда вы «заказываете» сертификат (обычно называемый SSL-сертификатом, хотя в настоящее время вместо него используется TLS — названия действительно прилипают!), CA могут позвонить вам или попросить изменить настройку DNS, чтобы убедиться, что вы контролируете данный домен. После завершения процесса проверки он выдаст сертификат, который затем можно установить на веб-серверы.
Затем клиенты, такие как браузеры, будут подключаться к вашим серверам и получать этот сертификат, чтобы они могли проверить его подлинность: браузеры имеют своего рода «отношения» с CA, в том смысле, что они отслеживают список доверенных доменов в CA чтобы убедиться, что сертификат действительно заслуживает доверия. Если сертификат не подписан доверенным органом, браузер отобразит большое информационное предупреждение для пользователей:
Мы на полпути к обеспечению связи между вами и вашей второй половиной: теперь, когда мы прошли аутентификацию (проверку личности вызывающего абонента), нам нужно убедиться, что мы можем общаться безопасно, без вмешательства других в процесс. Как я уже упоминал, вы находитесь прямо посреди собрания и вам нужно записать свой пароль для онлайн-банкинга. Вам нужно найти способ зашифровать ваше общение, чтобы только вы и ваша родственная душа могли понять ваш разговор.
Вы можете сделать это, установив общий секретный ключ между вами двумя и зашифровать сообщения с помощью этого ключа: например, вы можете использовать вариант шифра Цезаря, основанный на дате вашей свадьбы.
Это будет хорошо работать, если у обеих сторон есть установленные отношения, как у вас и вашей второй половинки, поскольку они могут создать ключ, основанный на общей памяти, о которой никто не знает. Браузеры и серверы, тем не менее, не могут использовать такой же механизм, поскольку они не знают друг друга заранее.
Вместо этого используются вариации протокола обмена ключами Диффи-Хеллмана, которые гарантируют, что стороны без предварительного знания устанавливают общий секретный ключ, и никто другой не сможет его «украсть». Это включает в себя использование математики.
Как только секретный ключ установлен, клиент и сервер могут общаться, не опасаясь, что кто-то может перехватить их сообщения. Даже если злоумышленники сделают это, у них не будет общего секретного ключа, необходимого для расшифровки сообщений.
Для получения дополнительной информации о HTTPS и Diffie-Hellman я бы порекомендовал прочитать «Как HTTPS защищает соединения» Хартли Броди и «Как HTTPS на самом деле работает?» Роберта Хитона. Кроме того, в «Девяти алгоритмах, которые изменили будущее» есть удивительная глава, в которой объясняется шифрование с открытым ключом, и я горячо рекомендую его фанатам компьютерных наук, интересующимся оригинальными алгоритмами.
HTTPS везде
Все еще решаете, должны ли вы поддерживать HTTPS на вашем сайте? У меня для вас плохие новости: браузеры начали защищать пользователей от веб-сайтов, не поддерживающих HTTPS, для того, чтобы «заставить» веб-разработчиков предоставлять полностью зашифрованные возможности просмотра.
За девизом «HTTPS везде» браузеры начали выступать против незашифрованных соединений — Google был первым поставщиком браузеров, который дал веб-разработчикам крайний срок, объявив, что начиная с Chrome 68 (июль 2018 года) он будет отмечать веб-сайты HTTP как «небезопасные»:
Еще более тревожным для веб-сайтов, не использующих преимущества HTTPS, является тот факт, что, как только пользователь вводит что-либо на веб-странице, метка «Небезопасно» становится красной — этот шаг должен побудить пользователей дважды подумать, прежде чем обмениваться данными с веб-сайтами, которые не поддерживает HTTPS.
Сравните это с тем, как выглядит сайт, работающий по HTTPS и имеющий действующий сертификат:
Теоретически, веб-сайт не должен быть безопасным, но на практике это отпугивает пользователей — и это справедливо. В те времена, когда H2 не было реальностью, имело бы смысл придерживаться незашифрованного, простого HTTP-трафика. В настоящее время практически нет причин для этого. Присоединяйтесь к движению “HTTPS везде” и помогите сделать Интернет более безопасным местом для серфинга.
GET vs POST
Как мы видели ранее, HTTP-запрос начинается со своеобразной “первой строки”:
Прежде всего, клиент сообщает серверу, какие методы он использует для выполнения запроса: базовые HTTP-методы включают GET, POST, PUT и DELETE, но список можно продолжить с менее распространенными (но все еще стандартными) методами, такими как TRACE, OPTIONS , или HEAD .
Теоретически, ни один метод не безопаснее других; на практике все не так просто.
GET-запросы обычно не содержат тела, поэтому параметры включаются в URL (например, www.example.com/articles?article_id=1 ), тогда как POST-запросы обычно используются для отправки («публикации») данных, которые включены в тело. Другое отличие заключается в побочных эффектах, которые несут эти методы: GET — идемпотентный метод, означающий, что независимо от того, сколько запросов вы отправите, вы не будете изменять состояние веб-сервера. Вместо этого POST не является идемпотентным: для каждого отправляемого вами запроса вы можете изменять состояние сервера (подумайте, например, о размещении нового платежа — теперь вы, вероятно, понимаете, почему сайты просят вас не обновлять страницу при выполнении сделки).
Чтобы проиллюстрировать важное различие между этими методами, нам нужно взглянуть на журналы веб-серверов, с которыми вы, возможно, уже знакомы:
192.168.99.1 — [192.168.99.1] — — [29/Jul/2018:00:39:47 +0000] «GET /?token=1234 HTTP/1.1» 200 525 «-» «Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36» 404 0.002 [example-local] 172.17.0.8:9090 525 0.002 200
192.168.99.1 — [192.168.99.1] — — [29/Jul/2018:00:40:47 +0000] «GET / HTTP/1.1» 200 525 «-» «Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36» 393 0.004 [example-local] 172.17.0.8:9090 525 0.004 200
192.168.99.1 — [192.168.99.1] — — [29/Jul/2018:00:41:34 +0000] «PUT /users HTTP/1.1» 201 23 «http://example.local/» «Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36» 4878 0.016 [example-local] 172.17.0.8:9090 23 0.016 201
Как вы видите, веб-серверы регистрируют путь запроса: это означает, что, если вы включите конфиденциальные данные в свой URL-адрес, они будут пропущены веб-сервером и сохранены где-то в ваших журналах — ваши конфиденциальные данные будут где-то в открытом тексте, чего нам нужно полностью избежать. Представьте, что злоумышленник сможет получить доступ к одному из ваших старых файлов-журналов, который может содержать информацию о кредитной карте, токены доступа для ваших приватных сервисов и т. д., это будет полной катастрофой.
Веб-серверы не журнализируют HTTP-заголовки и тела, так как сохраняемые данные будут слишком объемными — именно поэтому отправка информации через тело запроса, а не по URL-адресу, как правило, безопаснее. Отсюда мы можем вывести, что POST (и аналогичные неидемпотентные методы) безопаснее, чем GET , даже если это больше зависит от того, как данные отправляются при использовании определенного метода, а не от того, что конкретный метод по сути более безопасен, чем другие: если бы вы включили конфиденциальную информацию в тело запроса GET , то у вас не возникло бы больше проблем, чем при использовании POST , даже если такой подход был бы сочтен необычным.
Мы верим в заголовки HTTP
В этой статье мы рассмотрели HTTP, его развитие и то, как его безопасное расширение объединяет аутентификацию и шифрование, чтобы позволить клиентам и серверам обмениваться данными через безопасный канал: это не все, что HTTP может предложить с точки зрения безопасности.
Перевод выполнен при поддержке компании EDISON Software, которая профессионально занимается безопасностью, а так же разрабатывает системы электронной медицинской проверки.
Методы HTTP: GET vs. POST
Два наиболее часто используемые методы HTTP являются: GET и POST.
Что такое HTTP?
Протокол передачи гипертекста (HTTP) предназначена для обеспечения связи между клиентами и серверами.
HTTP работает в качестве протокола запроса-ответа между клиентом и сервером.
Веб-браузер может быть клиентом, а приложение на компьютере, на котором размещен веб-сайт может быть сервером.
Пример: клиент (браузер) подает запрос HTTP на сервер; то сервер возвращает ответ клиенту. Ответ содержит информацию о состоянии запроса и может также содержать запрошенное содержимое.
Два HTTP методы запроса: GET и POST
Два часто используемые методы для запроса-ответа между клиентом и сервером: GET и POST.
- GET — запрашивает данные из указанного ресурса
- POST — Отправляет данные, подлежащие обработке для указанного ресурса
Метод GET
Обратите внимание , что строка запроса (пары имя / значение) передается в URL запроса GET:
Некоторые другие заметки о запросах GET:
- GET запросы могут кэшироваться
- GET запросы остаются в истории браузера
- GET запросы могут быть закладкой
- не получать запросы не должны использоваться при работе с конфиденциальными данными
- GET запросы имеют ограничения длины
- GET запросы должны быть использованы только для получения данных
Метод POST
Обратите внимание , что строка запроса (пары имя / значение) передается в теле HTTP—сообщение запроса POST: