Содержание

Методы GET и POST. Использование и отличия

Рейтинг: 5 из 5, голосов 155

28 декабря 2019 г.

HTTP методы GET и POST используются для отправки данных на сервер.

Чаще всего методы используются в HTML формах, гиперссылках и AJAX запросах.

POST и GET запросы можно отправить на сервер с помощью любого программного обеспечения, работающего с протоколом HTTP.

Обработка запросов может отличаться в зависимости от типа сервера.

Большинство действующих сайтов работают с языком программирования PHP. В этом случае передаваемые данные попадают в суперглобальные массивы $_GET и $_POST.

Массивы $_GET и $_POST являются ассоциативными. Таким образом, переданный на сервер параметр с именем «user_name», будет доступен как $_GET[‘user_name’] или $_POST[‘user_name’] в зависимости от используемого метода.

Какой метод использовать GET или POST, чем отличаются методы

Основное отличие метода GET от POST в способе передачи данных.

Запрос GET передает данные в URL в виде пар «имя-значение» (другими словами, через ссылку), а запрос POST передает данные в теле запроса (подробно показано в примерах ниже). Это различие определяет свойства методов и ситуации, подходящие для использования того или иного HTTP метода.

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

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

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

HTTP метод POST поддерживает тип кодирования данных multipart/form-data, что позволяет передавать файлы.

Также следует заметить, что методы можно комбинировать. То есть, при необходимости вы можете отправить POST запрос на URL, имеющий GET параметры.

В каких случаях использовать POST и когда нужно использовать GET

В таблице ниже показаны распространенные варианты использования HTTP запросов с объяснением в чем разница между GET и POST запросами в конкретной ситуации.

Ситуация GET POST
Фильтр товаров

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

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

Форма авторизации

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

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

Онлайн заявка

Оформления заказа

Форма обратной
связи

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

Повторное обращение по конечной ссылке не приведет к повторной обработке запроса с введенными ранее параметрами.

Через гиперссылку

Переход по гиперссылке с параметрами равнозначен отправке запроса через HTML форму.

Нет технической возможности поместить POST запрос в гиперссылку.

AJAX запросы Используются оба метода. Выбор зависит от контекста. Принципы выбора метода такие же, как и для HTML форм.

Сравнительная таблица HTTP методов GET и POST

В таблице ниже приведены основные свойства и отличия GET и POST методов.

Свойство GET POST
Способ передачи данных Через URL В теле HTTP запроса
Защита данных

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

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

Длина запроса

Не более 2048 символов

Не ограничена

Примечание: ограничения могут быть установлены сервером.

Сохранение в закладки

Страница с параметрами может быть добавлена в закладки

Страница с параметрами не может быть добавлена в закладки.

Кэширование Страница с параметрами может быть кэширована Страница с параметрами не может быть кэширована
Индексирование поисковыми системами Страница с параметрами может быть индексирована Страница с параметрами не может быть индексирована
Возможность отправки файлов Не поддерживается Поддерживается
Поддерживаемые типы кодирования application/x-www-form-urlencoded

application/x-www-form-urlencoded

multipart/form-data

text/plain

Использование в гиперссылках <a> Да Нет
Использование в HTML формах Да
Да
Использование в AJAX запросах Да Да

Пример использования GET запроса

В примере показана простая HTML форма фильтра по нескольким параметрам.

HTML код формы, генерирующей GET запрос:

<form method="GET" name="filter" action="http://example.com/catalog/">
<p>Диагональ экрана</p>
<label><input type="radio" name="screen" value="4" checked> 4</label><br>
<label><input type="radio" name="screen" value="4.5"> 4.5</label><br>
<label><input type="radio" name="screen" value="5"> 5</label>
<p>Цвет</p>
<label><input type="checkbox" name="color_black" checked> Черный</label><br>
<label><input type="checkbox" name="color_white" checked> Белый</label><br>
<label><input type="checkbox" name="color_golden"> Золотой</label><br>
<input type="submit" value="Применить фильтр">
</form>

После отправки формы браузер переведет пользователя по ссылке:

http://example.com/catalog/?screen=4&color_black=on&color_white=on

Ссылка содержит URL документа, отвечающего за обработку и блок параметров. Знак «?» отмечает начало блока параметров GET запроса. Далее находятся пары «имя-значение», разделенные знаком «&». Имена параметров отделены от значений знаком «=».

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

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

В примере показана простая HTML форма авторизации.

HTML код формы, генерирующей POST запрос:

<form method="POST" name="authorization" action="http://example.com/profile.php">
Логин: <input type="text" name="username"><br>
Пароль: <input type="password" name="user_password"><br>
<input type="submit" value="Войти">
</form>

После отправки формы браузер переведет пользователя по ссылке:

http://example.com/profile.php

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

Запрос состоит из области заголовков и тела запроса.

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

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

by Lebedev

GET-запрос | База знаний

GET-запрос | База знаний

8 800 550–89–39+7 (499) 647–79–38

Включить защиту

Личный кабинет

Ru

Защита от DDoS

Защита сайтаХостинг с защитойЗащита сервисов TCP/UDPЗащита сети по BGPIP-транзит

Как это работает

Как работает StormWallТехнологииКак подключитьсяAPIБаза знаний

Партнерам

Для реселлеров и сервис-провайдеровWhite LabelПриведи друга

О компании

Почему StormWallМы защитилиБлогВакансииПресса о насО StormWall

Категории

Атака

Протокол

Термин

Команда

Запрос протокола HTTP к веб-серверу для получения нужной веб-клиенту информации. GET-запрос предоставляет возможность передачи параметров — на этом основан популярный сегодня механизм веб-сервисов.

Дата-центрColocationWAFDDoSSmurf-атакаХостингВыделенный серверСервер VDS/VPSIP-туннелированиеDDoS-атаки «нулевого» дня (Zero Day DDoS attack, 0day DDoS attack)Домен, или доменное имяРоутер или маршрутизаторСерверСетевой трафик (Traffic)Куки (Cookie)Сеть доставки контента (Content Delivery Network, CDN)Атаки на сайты95-й перцентильTLS fingerprintingTCP-рукопожатиеDNSBLMAC-адрес (Media Access Control) или физический адресDoSIP-адресПрокси-серверFirewall

Популярные новости

Количество и мощность DDoS-атак в России в 2021 году значительно возрастет

StormWall стал участником пиринговой сети по обмену трафиком Equinix IX (Франкфурт)

Доступен новый личный кабинет управления защитой от DDoS

Мы используем cookie, чтобы сделать сайт быстрее и удобнее. Продолжая пользоваться сайтом, Вы соглашаетесь с нашей Политикой конфиденциальности

Защита от DDoSЗащита сайтаХостинг с защитойЗащита сервисов TCP/UDPЗащита сети по BGPIP-транзит

CDN & WAFСеть доставки контента (CDN)Облачный WAF

Серверы и VPSVDS/VPS

Как это работаетКак работает StormWallТехнологииКак подключитьсяAPIБаза знаний

ПартнерамДля реселлеров и сервис-провайдеровWhite LabelПриведи друга

КомпанияПочему StormWallМы защитилиБлогВакансииПресса о насО StormWall

Защита от DDoS

Защита сайта

Хостинг с защитой

Защита сервисов TCP/UDP

Защита сети по BGP

IP-транзит

CDN & WAF

Сеть доставки контента (CDN)

Облачный WAF

Серверы и VPS

VDS/VPS

Как это работает

Как работает StormWall

Технологии

Как подключиться

API

База знаний

Партнерам

Для реселлеров и сервис-провайдеров

White Label

Приведи друга

Компания

Почему StormWall

Мы защитили

Блог

Вакансии

Пресса о нас

О StormWall

Ru

Способы оплаты

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

© 2013-

2022

StormWall.pro. All rights reserved Privacy Policy

Введение в REST-запросы и тестирование GET-запросов

Введение в REST-запросы и тестирование GET-запросов
18.12.2018 16:04

Автор: Кристин Джеквони (Kristin Jackvony)

Оригинал статьи: http://thethinkingtester.blogspot.ru/2018/02/introduction-to-rest-requests.html

http://thethinkingtester.blogspot.ru/2018/02/testing-get-requests.html

Перевод: Ольга Алифанова.

Все больше и больше компаний переходит на микросервисы в своих приложениях. Это означает, что разные секции приложения могут иметь отдельные хранилища данных и отдельные команды для взаимодействия с ними. Преимущество такого подхода в том, что в небольшой компонент внедрять изменения куда проще, нежели менять все приложение. Это также означает, что если упадет один микросервис, оставшаяся часть приложения продолжит функционировать. К примеру, представьте, что у вас есть сайт проката велосипедов. У него есть микросервис системы бронирования, и еще один – для учета оборудования. Если микросервис оборудования упадет, пользователи все равно смогут бронировать велосипеды, используя кэшированные данные сервиса оборудования.

Большинство микросервисов используют API – программные интерфейсы приложения, которые представляют собой наборы команд, описывающих, как можно использовать службу. Большая часть API использует REST-запросы (Representational State Transfer — «передача состояния представления») для отправки и получения данных.

Однако, несмотря на широкое применение REST API в современных приложениях, многие тестировщики даже не подозревают, как легко их тестировать! Эта статья – введение в REST-запросы и их использование в тестировании API.

Зачем же тестировать REST запросы, если можно просто подождать и тестировать через интерфейс? А вот почему:

  • Тестирование REST-запросов позволит найти баги раньше, иногда еще до того, как создан интерфейс!
  • Злоумышленники отлично знают, как делать REST-запросы, и могут пользоваться ими для эксплуатации уязвимостей приложения, делая запросы, которые не позволяет UI.
  • Эти запросы легко автоматизировать, и они в несколько раз быстрее, чем UI-автоматизация (см. мою статью про API и UI-автоматизацию).

Чтобы приступить к REST-тестированию, для начала подумайте, что вы видите в URL страницы, открывая сайт. К примеру, вы можете увидеть что-то вроде https://www.foobank.com/customers/login. Легко увидеть, как URL определяет, на какую страницу вы попали:

  • https означает, что это защищенный запрос,
  • www.footbank.com – это домен, который сообщает, что вы хотите попасть на сайт Foobank,
  • customers – это первая часть пути, информирующая, что вы пользователь и переходите в раздел сайта для пользователей,
  • login – финальная часть пути, говорящая о том, что вы хотите попасть на экран авторизации.

В URL не отображается только тип выполняемого REST-запроса. Они известны, как HTTP-глаголы, и их легко понять:

  • POST добавляет новую запись в базу данных.
  • GET получает запись из базы данных.
  • PUT берет запись из базы и заменяет ее новой.
  • PATCH меняет существующую в базе запись.
  • DELETE удаляет запись из базы.

Под «записью» в этом случае понимается любая секция сгруппированных вместе данных. К примеру, это может быть почтовый адрес пользователя, или вся его контактная информация, а также вообще все, связанное с этим конкретным пользователем. То, что входит в запись, зависит от создателей API.

Начнем изучение типов запросов REST с запросов GET. Обычно их легче всего тестировать, потому что все, что мы в этом случае делаем – это получаем данные из базы. Нам не надо волноваться о том, правильно ли мы манипулируем данные – нам просто нужно их получить и проверить, что мы получаем правильный ответ.

С моей точки зрения, два лучших инструмента для тестирования REST-запросов – это Swagger и Postman. Swagger -–это фреймворк с открытым исходным кодом, позволяющий разработчикам создавать документацию для REST API. Если у вашего API есть Swagger-файл, то будет легко увидеть, какие типы запросов API позволяет, и какие параметры необходимы этим запросам. Разработчики Swagger также создали образец приложения, которое можно использовать для практики REST-запросов: http://petstore.swagger.io. Этот сайт имитирует онлайн-зоомагазин, и пользователи могут добавлять и получать информацию о своих питомцах.


Зайдя на этот сайт, вы увидите, что там доступно множество возможных запросов к Pet. давайте посмотрим на запрос GET к /pet/{petID}. Нажмите на этот запрос, а затем на кнопку «Try it out». Вы увидите, что petId – это необходимый параметр. Введите 1 в поле параметра, и нажмите на «Execute». Проскролльте вниз к секции «Response Body», и вы увидите, что сервер вернул информацию о питомце! Проскролльте немного выше и посмотрите на URL запроса: http://petstore. swagger.io/v2/pet/1. Мы будем использовать этот URL, чтобы учиться делать запросы через Postman.

Postman – лучший из известных мне инструмент тестирования REST-запросов. Он бесплатно доступен на сайте https://www.getpostman.com, а еще у него есть платная командная версия. Если у вас еще нет Postman, скачайте и запустите его.


Postman должен стартовать на открытой вкладке, настроенной на использование GET-запроса. Все, что вам теперь остается сделать – это ввести URL запроса, который мы использовали ранее, и нажать «Send». Вы должны получить ответ, аналогичный ответу на этот запрос в Swagger.

Теперь, когда мы разобрались, как работают GET-запросы, давайте подумаем, как же их тестировать! Очевидно, что мы протестировали «счастливый» сценарий, получив питомца с id 1. Что будет, если мы изменим id-параметр на 2? А если на -1? На 0? На «foo»? Тут стоит упомянуть, что Swagger Pet Store – тестовое приложение, и вы можете увидеть в нем поведение, которое в реальном приложении будет нежелательным. К примеру, я получила результат, тестируя с параметром -1. Как правило, ожидается, что ID объектов данных не могут быть отрицательными, и в реальном приложении это было бы багом.

Давайте посмотрим, что будет, если мы вообще не будем вводить параметр, и наш URL запроса будет просто выглядеть как http://petstore.swagger.io/v2/pet. Мы получим XML-ответ, который гласит «unknown». Можно также заметить, что код ответа – 405 Method Not Allowed.


Коды статуса, полученные после отправки REST-запроса, сообщают вам о поведении вашего приложения. Мы еще будем их обсуждать, а пока давайте запомним, что код 200 – это хорошо, а код, начинающийся с 4, обычно означает, что что-то пошло не так. Скажем, вы можете получить статус 404 для питомца, которого не существует. Этот статус означает, что запись не найдена.

Вернемся к Swagger Pet Store и посмотрим на еще один GET-запрос. В этот раз это запрос pets/findByStatus. Нажмите на запрос, а затем на «Try it out».


Отметим, что для выполнения этого запроса нужно выбрать статус. Давайте выберем статус «sold» и нажмем на «Execute». Если вы проскроллите вниз до окна ответа, вы увидите, что сервер вернул множество питомцев. Теперь проскролльте чуть выше и посмотрите на URL запроса:

http://petstore.swagger.io/v2/pet/findByStatus?status=sold.

Вопросительный знак в URL означает, что мы использовали параметр запроса. Это немного отличается от параметра пути, который мы наблюдали, запрашивая GET по id питомца. Параметры запроса всегда начинаются с вопросительного знака. Затем идет имя параметра, знак равенства, и значение параметра, которое мы хотим использовать.

Скопируйте запрос и запустите его в Postman. Просто нажмите на кнопку «+» вверху экрана, чтобы открыть вкладку и создать новый запрос. По умолчанию он всегда GET. Введите URL и нажмите «Send». Вы должны получить результат, аналогичный прогону запроса в Swagger.

Мы протестировали один успешный сценарий для этого запроса. Его также можно прогнать с использованием значений параметра «available» и «pending». Вы можете запустить запрос http://petstore.swagger.io/v2/pet/findByStatus?status=pending,sold и получить всех забронированных и всех проданных питомцев! А что будет, если передать в параметре «foo»? вы получите пустой набор результатов. Это отличается от ответа, который мы получали, посылая «foo» как параметр для GET-запроса питомца по ID, и демонстрирует разницу между параметром запроса и параметром пути. Если параметра пути не существует, то обычно вы получите ошибку 400. Если не существует параметра запроса, то вы получите ответ 200 и пустой набор результатов в теле ответа.

Теперь, когда вы попробовали запустить два разных GET-запроса, можно тестировать дальше, манипулируя URL запросов различным образом. К примеру, посмотреть, что будет, если вы сделаете запрос к https вместо http. Или выяснить, как поведет себя система, если вы поменяете «io» в запросе на «com», или «v2» на «v1». Можно удалить «/pet». Можно попробовать изменить тип запроса на POST или DELETE. Наблюдения за тем, что происходит, помогут вам понять, как работают REST-запросы, и даст вам пищу для идей тестирования вашего API.

Больше информации по этой теме вы можете получить в курсе Тестирование REST API

Обсудить в форуме

Быстрый старт — Запросы документации 2.28.1

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

Во-первых, убедитесь, что:

Давайте начнем с нескольких простых примеров.

Сделать запрос

Сделать запрос с помощью Requests очень просто.

Начните с импорта модуля «Запросы»:

 >>> запросы на импорт
 

Теперь давайте попробуем получить веб-страницу. Для этого примера давайте получим общедоступный GitHub временная шкала:

 >>> r = request.get('https://api.github.com/events')
 

Теперь у нас есть объект Response с именем r . Мы можем получить всю необходимую нам информацию от этого объекта.

Простой API

Requests означает, что все формы HTTP-запросов очевидны. За например, вот как вы делаете запрос HTTP POST:

 >>> r = request.post('https://httpbin.org/post', data={'key': 'value'})
 

Красиво, правда? А как насчет других типов HTTP-запросов: PUT, DELETE, HEAD и ОПЦИИ? Все так же просто:

 >>> r = request.put('https://httpbin.org/put', data={'key': 'value'})
>>> r = request.delete('https://httpbin.org/delete')
>>> r = request.head('https://httpbin.org/get')
>>> r = request.options('https://httpbin.org/get')
 

Это все хорошо, но это только начало того, что могут сделать Запросы. делать.

Передача параметров в URL-адресах

Вы часто хотите отправить какие-то данные в строке запроса URL. Если вы создавали URL-адрес вручную, эти данные будут представлены как ключ/значение пары в URL-адресе после вопросительного знака, например. httpbin.org/get?key=val . Запросы позволяют вам предоставлять эти аргументы в виде словаря строк, используя аргумент ключевого слова params . Например, если вы хотите пройти key1=value1 и key2=value2 to httpbin.org/get , вы должны использовать следующий код:

 >>> полезная нагрузка = {'key1': 'value1', 'key2': 'value2'}
>>> r = request.get('https://httpbin.org/get', params=payload)
 

Вы можете убедиться, что URL-адрес был правильно закодирован, распечатав URL-адрес:

 >>> print(r.url)
https://httpbin.org/get?key2=value2&key1=value1
 

Обратите внимание, что любой ключ словаря, значение которого равно None , не будет добавлен в Строка запроса URL.

Вы также можете передать список элементов как значение:

 >>> полезная нагрузка = {'ключ1': 'значение1', 'ключ2': ['значение2', 'значение3']}
>>> r = request.get('https://httpbin.org/get', params=payload)
>>> напечатать(r.url)
https://httpbin. org/get?key1=value1&key2=value2&key2=value3
 

Содержание ответа

Мы можем прочитать содержимое ответа сервера. Рассмотрите временную шкалу GitHub еще раз:

 >>> запросы на импорт
>>> r = request.get('https://api.github.com/events')
>>> р.текст
'[{"репозиторий":{"open_issues":0,"url":"https://github.com/...
 

Запросы будут автоматически декодировать контент с сервера. Самый юникод кодировки легко декодируются.

Когда вы делаете запрос, Requests делает обоснованные предположения о кодировке ответ на основе заголовков HTTP. Кодировка текста, угадываемая Requests используется при доступе к р.текст . Вы можете узнать, что такое кодировка Requests using и измените его, используя свойство r.encoding :

 >>> р.кодировка
'утф-8'
>>> r.encoding = 'ISO-8859-1'
 

Если вы измените кодировку, запросы будут использовать новое значение r.encoding всякий раз, когда вы звоните r.text . Вы можете сделать это в любой ситуации, когда вы можете применить специальную логику, чтобы выяснить, какая кодировка контента будет быть. Например, HTML и XML имеют возможность указать свою кодировку в их тело. В таких ситуациях вы должны использовать r.content найти кодировку, а затем установите r.encoding . Это позволит вам использовать r.text с правильная кодировка.

Запросы

также будут использовать пользовательские кодировки, если они вам нужны. Если вы создали свою собственную кодировку и зарегистрировали ее с кодеками модуль, вы можете просто использовать имя кодека в качестве значения r.encoding и Запросы будут обрабатывать декодирование для вас.

Содержимое двоичного ответа

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

 >>> р.содержимое
b'[{"репозиторий":{"open_issues":0,"url":"https://github.com/...
 

Кодирование передачи gzip и deflate автоматически декодируется для вас.

Кодирование передачи br автоматически декодируется для вас, если библиотека Brotli например, brotli или brotlicffi.

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

 >>> из изображения импорта PIL
>>> из io импортировать BytesIO
>>> i = Image.open(BytesIO(r.content))
 

Содержимое ответа JSON

Также имеется встроенный декодер JSON, если вы имеете дело с данными JSON:

 >>> запросы на импорт
>>> r = request.get('https://api.github.com/events')
>>> р.json()
[{'репозиторий': {'open_issues': 0, 'url': 'https://github.com/...
 

В случае сбоя декодирования JSON r.json() вызывает исключение. Например, если ответ получает 204 (нет содержимого), или если ответ содержит недопустимый JSON, попытка r.json() вызывает request.exceptions.JSONDecodeError . Это исключение оболочки обеспечивает взаимодействие для нескольких исключений, которые могут быть вызваны разными версии python и библиотеки сериализации json.

Следует отметить, что успех вызова r.json() делает не указать успешность ответа. Некоторые серверы могут возвращать объект JSON в неудачный ответ (например, сведения об ошибке с HTTP 500). Такой JSON будет декодирован и вернулся. Чтобы проверить успешность запроса, используйте r.raise_for_status() или проверка r.status_code — это то, что вы ожидаете.

Необработанное содержимое ответа

В редких случаях, когда вы хотите получить необработанный ответ сокета от сервер, вы можете получить доступ к r.raw . Если вы хотите сделать это, убедитесь, что вы установили stream = True в вашем первоначальном запросе. Как только вы это сделаете, вы можете сделать это:

 >>> r = request.get('https://api.github.com/events', stream=True)
>>> r.raw

>>> r.raw.read(10)
'\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x03'
 

В целом, однако, вы должны использовать подобный шаблон, чтобы сохранить то, что передано в файл:

 с открытым (имя файла, 'wb') как fd:
    для чанка в r. iter_content(chunk_size=128):
        fd.write(чанк)
 

Использование Response.iter_content будет обрабатывать многое из того, что вы сделали бы в противном случае. приходится обрабатывать при использовании Response.raw напрямую. При потоковой передаче загрузки, указанный выше способ является предпочтительным и рекомендуемым способом получения содержание. Обратите внимание, что chunk_size можно свободно настроить на число, которое может лучше соответствовать вашим вариантам использования.

Note

Важное примечание об использовании Response.iter_content по сравнению с Response.raw . Response.iter_content автоматически декодирует gzip и deflate трансфер-кодировки. Response.raw — необработанный поток байтов. преобразовать содержимое ответа. Если вам действительно нужен доступ к байтам, поскольку они были возвращены, используйте Ответ. raw .

Более сложные запросы POST

Как правило, вы хотите отправить некоторые данные, закодированные в форме — очень похоже на HTML-форму. Для этого просто передайте словарь в аргумент data . Ваш словарь данных будет автоматически закодирован в форме при запросе:

 >>> полезная нагрузка = {'key1': 'value1', 'key2': 'value2'}
>>> r = request.post("https://httpbin.org/post", data=payload)
>>> печать (р.текст)
{
  ...
  "форма": {
    "ключ2": "значение2",
    "ключ1": "значение1"
  },
  ...
}
 

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

 >>> payload_tuples = [('ключ1', 'значение1'), ('ключ1', 'значение2')]
>>> r1 = request.post('https://httpbin.org/post', data=payload_tuples)
>>> payload_dict = {'key1': ['value1', 'value2']}
>>> r2 = request. post('https://httpbin.org/post', data=payload_dict)
>>> печать(r1.текст)
{
  ...
  "форма": {
    "ключ1": [
      "значение1",
      "значение2"
    ]
  },
  ...
}
>>> r1.текст == r2.текст
Истинный
 

В некоторых случаях вам может потребоваться отправить данные, не закодированные в форме. Если вы передаете строку вместо dict , эти данные будут отправлены напрямую.

Например, GitHub API v3 принимает данные POST/PATCH в формате JSON:

 >>> импортировать json
>>> url = 'https://api.github.com/some/endpoint'
>>> полезная нагрузка = {'некоторые': 'данные'}
>>> r = request.post(url, data=json.dumps(полезная нагрузка))
 

Обратите внимание, что приведенный выше код НЕ добавит Заголовок Content-Type (поэтому, в частности, он НЕ будет устанавливать его на application/json ).

Если вам нужен этот набор заголовков и вы не хотите самостоятельно кодировать dict , вы также можете передать его напрямую, используя параметр json (добавлен в версии 2. 4.2) и он будет закодирован автоматически:

 >>> url = 'https://api.github.com/some/endpoint'
>>> полезная нагрузка = {'некоторые': 'данные'}
 
 >>> r = request.post(url, json=полезная нагрузка)
 

Обратите внимание, что параметр json игнорируется, если передается либо данные , либо файлы .

POST файл, закодированный из нескольких частей

Запросы упрощают загрузку файлов с кодировкой Multipart:

 >>> URL = 'https://httpbin.org/post'
>>> files = {'файл': open('report.xls', 'rb')}
>>> r = request.post(url, files=файлы)
>>> р.текст
{
  ...
  "файлы": {
    "file": "<цензурированные...бинарные...данные>"
  },
  ...
}
 

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

 >>> URL = 'https://httpbin.org/post'
>>> files = {'file': ('report.xls', open('report.xls', 'rb'), 'application/vnd.ms-excel', {'Expires': '0'}) }
>>> r = request.post(url, files=файлы)
>>> р. текст
{
  ...
  "файлы": {
    "file": "<цензурированные...бинарные...данные>"
  },
  ...
}
 

При желании вы можете отправить строки для получения в виде файлов:

 >>> URL = 'https://httpbin.org/post'
>>> files = {'file': ('report.csv', 'some,data,to,send\nanother,row,to,send\n')}
>>> r = request.post(url, files=файлы)
>>> р.текст
{
  ...
  "файлы": {
    "file": "некоторые,данные,кому,отправить\\nanother,строка,кому,отправить\\n"
  },
  ...
}
 

Если вы публикуете очень большой файл как multipart/form-data запрос, вы можете захотеть передать запрос. По умолчанию запрашивает не поддерживают это, но есть отдельный пакет, который делает — запрашивает пояс с инструментами . Вы должны прочитать документацию по поясу инструментов для получения более подробной информации о том, как его использовать.

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

Предупреждение

Настоятельно рекомендуется открывать файлы в двоичном формате режим. Это связано с тем, что запросы могут пытаться предоставить Content-Length заголовок для вас, и если он делает это значение будет установлено число байт в файле. Могут возникать ошибки если открыть файл в текстовом режиме .

Коды состояния ответа

Мы можем проверить код состояния ответа:

 >>> r = request.get('https://httpbin.org/get')
>>> r.status_code
200
 

Requests также поставляется со встроенным объектом поиска кода состояния для легкого ссылка:

 >>> r.status_code == request.codes.ok
Истинный
 

Если мы сделали неверный запрос (ошибка клиента 4XX или ответ об ошибке сервера 5XX), мы может поднять его с Ответ.raise_for_status() :

 >>> bad_r = request.get('https://httpbin.org/status/404')
>>> bad_r.status_code
404
>>> bad_r.raise_for_status()
Traceback (последний последний вызов):
  Файл "requests/models.py", строка 832, в raise_for_status
    поднять http_error
запросы. исключения.HTTPError: 404 Ошибка клиента
 

Но, так как наши status_code для r было 200 , когда мы звоним raise_for_status() получаем:

 >>> r.raise_for_status()
Никто
 

Все хорошо.

Печенье

Если ответ содержит несколько файлов cookie, вы можете быстро получить к ним доступ:

 >>> url = 'http://example.com/some/cookie/setting/url'
>>> r = запросы.get(url)
>>> r.cookies['example_cookie_name']
'example_cookie_value'
 

Чтобы отправить собственные файлы cookie на сервер, вы можете использовать печенье параметр:

 >>> URL = 'https://httpbin.org/cookies'
>>> cookies = dict(cookies_are='working')
>>> r = request.get(url, cookies=cookies)
>>> р.текст
'{"cookies": {"cookies_are": "рабочие"}}'
 

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

 >>> jar = запросы.cookies.RequestsCookieJar()
>>> jar.set('tasty_cookie', 'ням', domain='httpbin.org', path='/cookies')
>>> jar.set('gross_cookie', 'blech', domain='httpbin.org', path='/в другом месте')
>>> URL = 'https://httpbin.org/cookies'
>>> r = request.get(url, cookies=jar)
>>> р.текст
'{"cookies": {"tasty_cookie": "ням"}}'
 

Перенаправление и история

По умолчанию запросы будут выполнять перенаправление местоположения для всех команд, кроме ГЛАВА.

Мы можем использовать свойство history объекта Response для отслеживания перенаправления.

Список Response.history содержит Ответ объектов, созданных для завершить запрос. Список отсортирован от самого старого к самому последнему отклик.

Например, GitHub перенаправляет все HTTP-запросы на HTTPS:

 >>> r = request.get('http://github.com/')
>>> р.url
'https://github. com/'
>>> r.status_code
200
>>> р.история
[<Ответ [301]>]
 

Если вы используете GET, OPTIONS, POST, PUT, PATCH или DELETE, вы можете отключить обработка перенаправления с параметром allow_redirects :

 >>> r = request.get('http://github.com/', allow_redirects=False)
>>> r.status_code
301
>>> р.история
[]
 

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

 >>> r = request.head('http://github.com/', allow_redirects=True)
>>> р.url
'https://github.com/'
>>> р.история
[<Ответ [301]>]
 

Тайм-ауты

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

 >>> request.get('https://github.com/', timeout=0.001)
Traceback (последний последний вызов):
  Файл "", строка 1, в 
request. exceptions.Timeout: HTTPConnectionPool (host = 'github.com', port = 80): время ожидания запроса истекло. (время ожидания = 0,001)
 

Примечание

тайм-аут не является ограничением по времени на загрузку всего ответа; скорее, исключение возникает, если сервер не выдал ответ на тайм-аут секунды (точнее, если ни один байт не был получено на базовом сокете в течение тайм-аута секунд). Если тайм-аут не указан явно, запросы не тайм-аут.

Ошибки и исключения

В случае проблемы с сетью (например, сбой DNS, отказ в подключении и т. д.) Запросы поднимут Исключение ConnectionError .

Response.raise_for_status() будет поднять HTTPError , если HTTP-запрос вернул неудачный код состояния.

Если время ожидания запроса истекает, возникает исключение Timeout . поднятый.

Если запрос превышает настроенное максимальное количество перенаправлений, Возникает исключение TooManyRedirects .

Все исключения, явно вызываемые Requests, наследуются от запросы.исключения.RequestException .


Готовы к большему? Загляните в расширенный раздел.

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

GET и POST — разница и сравнение

Различия в отправке форм

Фундаментальное различие между METHOD=»GET» и METHOD=»POST» заключается в том, что они соответствуют различным HTTP-запросам , как определено в спецификациях HTTP. Процесс отправки для обоих методов начинается одинаково — набор данных формы создается браузером, а затем кодируется способом, указанным атрибутом enctype . Для METHOD=»POST атрибут enctype может быть multipart/form-data или application/x-www-form-urlencoded , тогда как для METHOD=»GET» только application/x- Допускается www-form-urlencoded . Этот набор данных формы затем передается на сервер.

Для отправки формы с METHOD=»GET» браузер создает URL-адрес, принимая значение атрибута action , добавляя ? , а затем добавить набор данных формы (закодированный с использованием типа содержимого application/x-www-form-urlencoded). Затем браузер обрабатывает этот URL-адрес, как если бы он перешел по ссылке (или как если бы пользователь ввел URL-адрес напрямую). Браузер делит URL-адрес на части и распознает хост, а затем отправляет этому хосту запрос GET с остальной частью URL-адреса в качестве аргумента. Сервер берет его оттуда. Обратите внимание, что этот процесс означает, что данные формы ограничены кодами ASCII. Особое внимание следует уделить кодированию и декодированию других типов символов при их передаче через URL-адрес в формате ASCII.

Отправка формы с параметром METHOD=»POST» приводит к отправке запроса POST с использованием значения атрибута action и сообщения, созданного в соответствии с типом содержимого, указанным атрибутом enctype .

Плюсы и минусы

Поскольку данные формы отправляются как часть URL-адреса при использовании GET

  • Данные формы ограничены кодами ASCII. Особое внимание следует уделить кодированию и декодированию других типов символов при их передаче через URL-адрес в формате ASCII. С другой стороны, двоичные данные, изображения и другие файлы могут быть отправлены через МЕТОД = «ПОСТ»
  • Все заполненные данные формы отображаются в URL-адресе. Кроме того, он также хранится в истории/журналах просмотра веб-страниц пользователя для браузера. Эти проблемы делают GET менее безопасным.
  • Однако одно из преимуществ отправки данных формы как части URL-адреса заключается в том, что можно добавлять URL-адреса в закладки и напрямую использовать их, полностью минуя процесс заполнения формы.
  • Существует ограничение на объем данных формы, которые можно отправить, поскольку длина URL-адреса ограничена.
  • Script kiddies могут более легко обнаруживать уязвимости в системе, чтобы взломать ее. Например, Citibank был взломан путем изменения номеров счетов в строке URL. [1] Конечно, опытные хакеры или веб-разработчики могут выявить такие уязвимости, даже если используется POST; это просто немного сложнее. Как правило, сервер должен с подозрением относиться к любым данным, отправляемым клиентом, и защищаться от небезопасных прямых ссылок на объекты.

Различия в обработке на стороне сервера

В принципе, обработка отправленных данных формы зависит от того, отправляются ли они с помощью METHOD=»GET» или METHOD=»POST» . Поскольку данные кодируются по-разному, необходимы разные механизмы декодирования. Таким образом, вообще говоря, изменение МЕТОДА может потребовать изменения сценария, обрабатывающего отправку. Например, при использовании интерфейса CGI сценарий получает данные в переменной среды (QUERYSTRING), когда используется GET . Но когда Используется POST , данные формы передаются в стандартном потоке ввода ( stdin ), а количество байтов для чтения задается заголовком Content-length.

Что происходит при конфликте переменных GET и POST?

В некоторых языках, таких как PHP, информация из параметров GET и POST, помимо того, что доступна отдельно, также объединена в вспомогательную переменную, например, $_REQUEST в PHP. Если возникает конфликт, т. е. одно и то же имя параметра используется с разными значениями в GET и POST, то конфликт разрешается с помощью определенных правил. В случае PHP приоритет определяется variable_order директива конфигурации. Порядок по умолчанию — EGPCS (среда, GET, POST, Cookie, сервер). Это означает, что переменная в $_GET имеет приоритет над $_POST, которая, в свою очередь, имеет приоритет над $_COOKIE.

Рекомендуемое использование

GET рекомендуется использовать при отправке «идемпотентных» форм — тех, которые «значительно не изменяют состояние мира». Другими словами, формы, которые включают только запросы к базе данных. Другая точка зрения состоит в том, что несколько идемпотентных запросов будут иметь тот же эффект, что и один запрос. Если речь идет об обновлениях базы данных или других действиях, таких как запуск электронных писем, рекомендуется использовать POST.

Из блога разработчиков Dropbox:

браузер не знает точно, что делает конкретная HTML-форма, но если форма отправляется через HTTP GET, браузер знает, что безопасно автоматически повторить попытку отправки в случае сетевой ошибки. Для форм, использующих HTTP POST, повторная попытка может быть небезопасной, поэтому браузер сначала запрашивает у пользователя подтверждение.

Запрос «GET» часто можно кэшировать, а запрос «POST» вряд ли. Для систем запросов это может иметь значительное влияние на эффективность, особенно если строки запросов простые, поскольку кэши могут обслуживать наиболее частые запросы.

В некоторых случаях рекомендуется использовать POST даже для идемпотентных запросов:

  • Если данные формы будут содержать символы, отличные от ASCII (например, символы с диакритическими знаками), то METHOD=»GET» в принципе неприменим, хотя на практике может работать (в основном для символов ISO Latin 1).
  • Если набор данных формы большой — скажем, сотни символов — тогда METHOD=»GET» может вызвать практические проблемы с реализациями, которые не могут обрабатывать такие длинные URL-адреса.
  • Возможно, вы захотите избежать METHOD=»GET» , чтобы пользователи не видели, как работает форма, особенно для того, чтобы сделать «скрытые» поля (INPUT TYPE=»HIDDEN») более скрытыми, не отображая в URL. Но даже если вы используете скрытые поля с METHOD=»POST» , они все равно будут отображаться в исходном коде HTML.

А как насчет HTTPS?

Обновлено 15 мая 2015 г. В частности, при использовании HTTPS (HTTP через TLS/SSL) обеспечивает ли POST больше безопасности, чем GET?

Интересный вопрос. Скажем, вы делаете запрос GET на веб-страницу:

 ПОЛУЧИТЬ https://www.example.com/login.php?user=mickey&passwd=mini
 

Если предположить, что ваше интернет-соединение отслеживается, какая информация об этом запросе будет доступна шпиону? Если вместо этого используется POST, а данные пользователя и пароля включены в переменные POST, будет ли это более безопасным в случае соединений HTTPS?

Нет. Если вы сделаете такой GET-запрос, злоумышленнику, отслеживающему ваш веб-трафик, будет известна только следующая информация:

  1. Тот факт, что вы установили HTTPS-соединение
  2. Имя хоста – www.example.com
  3. Общая длина запроса
  4. Длина ответа

Часть пути URL-адреса — т. е. фактическая запрошенная страница, а также параметры строки запроса — защищены (зашифрованы), пока они находятся «по сети», т. е. в пути на пути к целевому серверу. Точно такая же ситуация и с POST-запросами.

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

Ссылки

  • wikipedia:POST (HTTP)
  • Методы HTTP-запроса
  • Сообщение HTTP — W3. org
  • Получение HTTP — W3.org
  • Скрывает ли HTTPS доступ к URL-адресам? — Обмен стека

HTTP/1.1: запрос

HTTP/1.1: запрос
часть протокола передачи гипертекста — HTTP/1.1
RFC 2616 Филдинг и др.

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

 Запрос = Строка Запроса ; Раздел 5.1
                        *(( общий заголовок ; Раздел 4.5
                         | заголовок запроса; Раздел 5.3
                         | заголовок объекта ) CRLF) ; Раздел 7.1
                        CRLF
                        [тело сообщения]; Раздел 4.3
 

5.1 Строка запроса

Строка запроса начинается с маркера метода, за которым следует Request-URI и версия протокола, заканчивающаяся на CRLF. элементы разделяются символами SP. CR или LF не допускаются за исключением последней последовательности CRLF.

 Request-Line = Method SP Request-URI SP HTTP-Version CRLF
 

5.1.1 Метод

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

 Метод = "ВАРИАНТЫ" ; Раздел 9.2
                      | "ПОЛУЧИТЬ"                    ; Раздел 9.3
                      | "ГЛАВА"                   ; Раздел 9.4
                      | "ПОЧТА"                   ; Раздел 9.5
                      | "ПОМЕЩАТЬ"                    ; Раздел 9.6
                      | "УДАЛИТЬ"                 ; Раздел 9.7
                      | "СЛЕД"                  ; Раздел 9.8
                      | "СОЕДИНЯТЬ"                ; Раздел 9.9
                      | метод расширения
       метод расширения = токен
 

Список методов, разрешенных ресурсом, можно указать в Разрешить поле заголовка (раздел 14. 7). Код возврата ответа всегда уведомляет клиента, разрешен ли метод в настоящее время для ресурс, так как набор разрешенных методов может динамически меняться. Ан Исходный сервер ДОЛЖЕН возвращать код состояния 405 (метод не разрешен) если метод известен исходному серверу, но не разрешен для запрошенный ресурс и 501 (не реализовано), если метод не распознан или не реализован исходным сервером. Методы ПОЛУЧИТЬ и HEAD ДОЛЖЕН поддерживаться всеми серверами общего назначения. Все остальные методы НЕОБЯЗАТЕЛЬНЫ; однако, если вышеуказанные методы реализованы, они ДОЛЖНЫ быть реализованы с той же семантикой, что и указанные в разделе 9.

5.1.2 URI запроса

Request-URI является универсальным идентификатором ресурса (раздел 3.2) и идентифицирует ресурс, к которому применяется запрос.

 Request-URI = "*" | абсолютныйURI | абс_путь | орган власти
 

Четыре варианта Request-URI зависят от характера запрос. Звездочка «*» означает, что запрос не относится к конкретному ресурсу, а самому серверу и разрешено только когда используемый метод не обязательно относится к ресурсу. Один пример был бы

 ВАРИАНТЫ * HTTP/1.1
 

Форма absoluteURI НЕОБХОДИМА при отправке запроса прокси. Прокси запрашивается для пересылки запроса или его обслуживания из допустимого кеша и вернуть ответ. Обратите внимание, что прокси МОЖЕТ перенаправить запрос на другой прокси или напрямую на сервер

определяется абсолютнымURI. Чтобы избежать циклов запросов, прокси-сервер ДОЛЖЕН уметь распознавать все имена своих серверов, включая любые псевдонимы, локальные варианты и числовой IP-адрес. Пример Строка запроса будет:

 ПОЛУЧИТЬ http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
 

Чтобы разрешить переход на absoluteURI во всех запросах в будущем версии HTTP, все серверы HTTP/1.1 ДОЛЖНЫ принимать абсолютный URI формы в запросах, хотя клиенты HTTP/1. 1 будут генерировать только их в запросах к прокси.

Форма полномочий используется только методом CONNECT (раздел 9.9).

Наиболее распространенная форма Request-URI используется для идентификации ресурс на исходном сервере или шлюзе. В этом случае абсолютный путь URI ДОЛЖЕН быть передан (см. раздел 3.2.1, abs_path) как Request-URI и сетевое расположение URI (авторитета) ДОЛЖНЫ передаваться в поле заголовка Host. Например, клиент, желающий чтобы получить указанный выше ресурс непосредственно с исходного сервера, создайте TCP-соединение с портом 80 хоста «www.w3.org» и отправьте линии:

 ПОЛУЧИТЬ /pub/WWW/TheProject.html HTTP/1.1
       Хост: www.w3.org
 

за которым следует оставшаяся часть запроса. Обратите внимание, что абсолютный путь не может быть пустым; если его нет в исходном URI, он ДОЛЖЕН быть указывается как «/» (корневой каталог сервера).

Request-URI передается в формате, указанном в разделе 3. 2.1. Если Request-URI закодирован с использованием кодировки «% HEX HEX» [42], исходный сервер ДОЛЖЕН декодировать Request-URI, чтобы правильно интерпретировать запрос. Серверы ДОЛЖНЫ отвечать на недопустимые Request-URI с соответствующим кодом состояния.

Прозрачный прокси НЕ ДОЛЖЕН перезаписывать часть «abs_path» полученный Request-URI при пересылке на следующий входящий сервер, кроме как указано выше, чтобы заменить null abs_path на «/».

 Примечание. Правило «без перезаписи» запрещает прокси-серверу изменять
      значение запроса, когда исходный сервер неправильно использует
      незарезервированный символ URI для зарезервированных целей. Разработчики
      следует знать, что некоторые прокси до HTTP/1.1, как известно,
      перепишите Request-URI.
 

5.2 Ресурс, идентифицируемый запросом

Точный ресурс, идентифицируемый интернет-запросом, определяется проверка как Request-URI, так и поля заголовка Host.

Исходный сервер, который не позволяет ресурсам различаться запрошенный хост МОЖЕТ игнорировать значение поля заголовка Host, когда определение ресурса, идентифицированного запросом HTTP/1.1. (Но см. раздел 19.6.1.1 для других требований к поддержке хоста в HTTP/1.1.)

Исходный сервер, который различает ресурсы в зависимости от хоста. запрошенный (иногда называемый виртуальным хостом или тщеславным хостом имена) ДОЛЖНЫ использоваться следующие правила для определения запрошенного ресурс по запросу HTTP/1.1:

1. Если Request-URI является absoluteURI, хост является частью Запрос-URI. Любое значение поля заголовка Host в запросе ДОЛЖНО быть игнорируется.

2. Если Request-URI не является absoluteURI и запрос включает поле заголовка Host, хост определяется заголовком Host значение поля.

3. Если хост, как определено правилом 1 или 2, не является допустимым хостом на сервер, ответ ДОЛЖЕН быть сообщением об ошибке 400 (Bad Request).

Получатели запроса HTTP/1.0, в котором отсутствует поле заголовка узла, МОГУТ попытка использовать эвристику (например, проверка пути URI для что-то уникальное для конкретного хоста), чтобы определить, что запрашивается точный ресурс.

5.3 Поля заголовка запроса

Поля заголовка запроса позволяют клиенту передавать дополнительные информацию о запросе и о самом клиенте сервер. Эти поля действуют как модификаторы запроса с семантикой. эквивалентно параметрам метода языка программирования призыв.

 заголовок запроса = Принять ; Раздел 14.1
                      | Принять кодировку; Раздел 14.2
                      | Принять кодировку ; Раздел 14.3
                      | Принять-Язык ; Раздел 14.4
                      | Авторизация ; Раздел 14.8
                      | Ожидать                   ; Раздел 14.20
                      | Из                     ; Раздел 14.22
                      | Хозяин                     ; Раздел 14.