Python requests вывести headers

Получение/отправка заголовков сервера модулем requests в Python.

Получение заголовков headers в ответе сервера.

Заголовки/header ответа сервера, т.е. которые сервер отправил обратно, доступны после запроса к серверу, в атрибуте Response.headers . Эти заголовки, модуль requests возвращает в виде словаря Python:

НО словарь особенный: он создан только для HTTP-заголовков. Согласно RFC 7230, имена заголовков HTTP не чувствительны к регистру символов.

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

Заголовки также особенные, т.к. сервер может отправить один и тот же заголовок несколько раз с разными значениями, но запросы объединяют их таким образом, чтобы они могут быть представлены в словаре в рамках одного сопоставления, согласно RFC 7230:

Получатель МОЖЕТ объединить несколько полей заголовка с одним и тем же именем поля в одну пару “field-name: field-value”, не изменяя семантику сообщения, добавляя каждое последующее значение поля к объединенному значению поля по порядку, разделенному запятой.

Если необходимо получить заголовки, которые МЫ отправили серверу, то просто получаем доступ к запросу, а затем к заголовкам запроса:

Читайте также:  Как отстирать старую траву с джинс

Отправка заголовков headers на сервер в запросе.

Если необходимо добавить в запрос пользовательские HTTP-заголовки, то просто передайте словарь со своими заголовками в аргумент headers метода requests.get() .

Например, в предыдущих примерах мы не указывали/устанавливали user-agent (тип браузера):

Примечание: Пользовательские заголовки имеют меньший приоритет, чем более конкретные источники информации. Например:

    Заголовки авторизации, заданные с помощью аргумента headers , будут переопределены, если учетные данные указаны в файле .netrc , который, в свою очередь, будет переопределен аргументом auth . Модуль requests будет искать файл netrc по адресу

/_netrc или по пути, указанному переменной среды NETRC .

  • Заголовки авторизации будут удалены, если будет сделано перенаправление за пределы хоста.
  • Заголовки авторизации прокси-сервера будут переопределены учетными данными прокси-сервера, указанными в URL-адресе.
  • Заголовки Content-Length будут переопределены, когда можно будет определить длину содержимого ответа.
  • Кроме того, запросы вообще не меняют свое поведение в зависимости от того, какие пользовательские заголовки указаны. Заголовки просто передаются в окончательный запрос.

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

    Источник

    Продвинутое руководство по библиотеке Python Requests

    В этом материале описаны продвинутые функции библиотеки Requests.

    Объекты Session

    Объект Session позволяет сохранять определенные параметры между запросами. Он же сохраняет куки всех запросов, сделанных из экземпляра Session .

    Объект Session включает все методы основного API Requests.

    Попробуем передать куки между запросами:

    Session могут также использоваться для предоставления данных по умолчанию для методов запроса. Для этого их нужно передать в параметры объекта:

    Любые словари, переданные методу запроса? будут объединены с заданными значениями уровня сессии. Параметры уровня методов перезаписывают параметры сессии.

    Удалите значение из параметра словаря:
    Иногда нужно будет не включать ключи уровня сессии в параметры словаря. Для этого необходимо установить значения ключа None в параметре уровня методов. Они будут пропускаться автоматически.

    Все значения, содержащиеся в сессии, прямо доступны. Подробнее об этом в документации API Session.

    Объекты запросов и ответов

    Каждый раз при вызове запроса происходят две вещи. Во-первых, создается объект Request , который будет направлен на сервер, чтобы сделать запрос или вернуть определенный ресурс. Во-вторых, когда библиотека получает ответ от сервера, генерируется объект Response . Он содержит всю информацию, которую вернул сервер и оригинальный объект Request . Вот простой запрос для получения крайне важной информации с серверов Википедии:

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

    А если нужны те, что были направлены серверу, тогда сперва нужно получить доступ к запросу, а потом — к его заголовкам:

    Подготовка запросов

    При получении объекта Response от вызова API или Session , используется атрибут PreparedRequest функции request . В некоторых случаях над телом и заголовками (и чем угодно еще) можно будет провести дополнительную работу перед отправкой запроса. Простейший способ следующий:

    Поскольку с объектом Request не происходит ничего особенного, его можно сразу подготовить и изменить объект PreparedRequest . Затем он отправляется с остальными параметрами, которые вы бы отправили в requests.* или Session.* .

    Однако этот код лишен кое-каких преимуществ использования объекта Session . Если точнее, состояние уровня Session , например куки, не будет применено к запросу. Чтобы получить PreparedRequest с примененным состоянием, замените вызов к Request.prepare() вызовом к Session.prepare_request() :

    При использовании потока “prepared request” помните, что он не учитывает окружение. Это может привести к проблемам в том случае, если переменные окружения используются для изменения поведения запросов. Например: самозаверенные SSL-сертификаты, определенные в REQUESTS_CA_BUNDLE , учитываться не будут. Результат — SSL: CERTIFICATE_VERIFY_FAILED . Обойти это поведение можно, явно объединив настройки окружения с сессией:

    Проверка сертификата SSL

    Библиотека Requests может верифицировать SSL-сертификаты для HTTPS-запросов так же, как и браузер. Для проверки сертификата хоста, нужно просто добавить аргумент verify :

    Если такового нет или он недействителен, вернется ошибка SSLError. Но у Github, например, есть:

    verify можно передать и файлу CA_BUNDLE для частных сертификатов. Или же настроить переменную среды REQUESTS_CA_BUNDLE .

    Библиотека может игнорировать проверку SSL-сертификатов, если значение verify — False .

    По умолчанию значение verify — True . Параметр подходит только для сертификатов хостов.

    Можно также определить файл локального сертификата в виде пути или пары ключ-значение:

    Если указан неправильный путь или недействительный сертификат, произойдет следующее:

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

    По умолчанию при запросе тело ответа загружается сразу же. Переписать это поведение и отсрочить загрузку тела ответа до того момента, пока не будет получен доступ к атрибуту Response.content , можно с помощью параметра stream :

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

    Можно и дальше контролировать процесс работы с помощью методов Response.iter_content и Response.iter_lines или чтения их из лежащей в основе библиотеки urllib3 urllib3.HTTPResponse в Response.raw .

    Постоянное соединение

    Благодаря urllib3 постоянное соединение поддерживается на 100% автоматически прямо в сессии. Любые запросы в сессии будут автоматически использовать соответствующее соединение.

    Стоит отметить, что соединения сбрасываются и возвращаются в пул для повторного использовать только после чтения данных тела. Важно задать значение stream равным False или читать свойство property объекта Response .

    Потоковые загрузки

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

    Запросы для данных, разбитых на части (chunk-encoded)

    Requests также поддерживает механизм передачи с разбиением на части для входящих и исходящих запросов. Для отправления такого нужно предоставить генератор (или любой итератор без определенной длины) в data :

    POST для нескольких файлов типа multipart

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

    Чтобы сделать это, просто представьте файлы в виде списка кортежей такого формата (form_field_name, file_info) :

    Предупреждение:
    Рекомендуется открывать файлы в бинарном режиме. Это важно, потому что Requests может попробовать предоставить заголовок Content-Length . В таком случае значением будет количеством байт в файле. А ошибки возникнут, если открыть файл в текстовом режиме.

    Хуки (перехват управления)

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

    • response : ответ, сгенерированный из объекта Request .

    Можно назначать функцию перехвата для каждого запроса, передавая словарь в параметр запроса hooks :

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

    Если при выполнении обратного вызова произойдет ошибка, отобразится предупреждение.

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

    Выведем некоторые аргументы метода запроса:

    Собственная аутентификация

    Requests позволяет указать собственный механизм аутентификации.

    Любой вызываемый объект, передаваемый в качестве аргумента auth методу запроса, может изменить запрос до его отправки.

    Реализации аутентификации — это подклассы requests.auth.AuthBase , и их легко определить. Requests предоставляет две общие схемы реализации аутентификации в requests.auth:HTTPBasicAuth и HTTPDigestAuth .

    Представим, что есть веб-сервис, который отвечает только в том случае, если значение заголовка X-Pizza — значение пароля. Такое маловероятно, но мало ли.

    Теперь можно сделать запрос с помощью PizzaAuth :

    Потоковые запросы

    С помощью requests.Response.iter_lines() можно запросто перебирать потоковые API, такие как Twitter Streaming API.

    Используем его для отслеживания ключа словаря requests :

    Прокси

    Если есть необходимость использовать прокси, можно настроить индивидуальные запросы с помощью аргумента proxies для любого метода запроса:

    Также их можно настроить с помощью переменных среды HTTP_PROXY и HTTPS_PROXY .

    Для использования HTTP Basic Auth (аутентификации) со своим прокси, используется синтаксис http://user:password@host/ :

    SOCKS

    В дополнение к базовым прокси HTTP Requests также поддерживает прокси с помощью протокола SOCKS. Это опциональная функция, требующая дополнительных библиотек. Их можно получить с помощью pip :

    После установки использовать прокси SOCKS так же просто, как и HTTP:

    При использовании socks5 разрешение DNS работает на стороне клиента, а не на стороне прокси-сервера. Это работает в соответствии с curl, который использует схему, чтобы определять, на чьей стороне разрешать DNS. Если необходимо заниматься преобразованием на стороне прокси-сервера, тогда используется socks5h .

    Соответствие стандартам

    Requests соответствует всем актуальным спецификациям и RFC (технические стандарты, применяемые в сети) там, где подобное соответствие не создает трудностей для пользователей. Такое внимание к спецификациям может привести к необычному поведению, которое покажется необычным для тех, кто не знаком с ними.

    Кодировки

    Когда вы получаете ответ, Requests предполагает, какую кодировку использовать для декодирования во время вызова метода Response.text . Библиотека сначала проверит кодировку в заголовке HTTP, и если там ничего не указано, воспользуется charade , чтобы попробовать угадать.

    Она не будет вести себя подобным образом только в одном случае — если кодировка не указано явно, а значение Content-Type — text . В таком случае, согласно RFC 2616, кодировка по умолчанию — ISO-8859-1 . Библиотека следует этому правилу. Если вам требуется другая кодировка, вы можете вручную настроить свойство Response. encoding или использовать сырой Response.content .

    Методы HTTP

    Requests предоставляет доступ ко всем методам HTTP: GET, OPTIONS, HEAD, POST, PUT, PATCH, DELETE . Далее будут детальные примеры того, как их использовать с GitHub API.

    Начнем с самого популярного метода — GET . GET — это идемпотентный метод, который возвращает ресурс по заданному URL. Он используется для получения данных из определенного места. Пример — попытка получить информацию об определенном коммите из GitHub. Пусть будет коммит a050faf . Это будет выглядеть вот так:

    Нужно подтвердить, что GitHub ответил правильно. Если да — необходимо определить тип контента. Это делается следующим образом:

    Итак, GitHub возвращает JSON . Можно использовать метод r.json для парсинга его в объекты Python.

    Пока что все просто. Но посмотрим, что еще есть в API GitHub. Можно просто почитать документацию, но еще интереснее, если просто поэкспериментировать с Requests. Используем метод OPTIONS , чтобы увидеть какие еще методы HTTP поддерживаются для этого ресурса.

    Оказывается, что у GitHub, как и у многих API, не реализован метод OPTIONS . Так что придется все-таки использовать документацию. Но если бы метод OPTION был реализован, он вернул бы примерно следующее.

    В документации указано, что единственные разрешенные методы для коммитов — POST . Они создают новые коммиты. Но поскольку используется репозиторий Requests, лучше не делать туда бесполезные POST . Вместо этого можно поиграть с функцией Issues.

    Эта документация была добавлена в ответ на “Issue #482”. Возьмем ее в качестве примера.

    Есть три комментария. Рассмотрим последний из них.

    Можем сообщить автору, что он не прав. Но сперва узнаем, кто это.

    Теперь скажем этому kennethreitz , что ему лучше отправляться в раздел для начинающих. Согласно документации API GitHub это делается с помощью метода POST.

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

    Теперь попробуем отредактировать сообщение. Для этого нужен метод PATCH .

    С баловством покончено. Используем DELETE для удаления сообщения.

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

    Осталось написать программу на Python, которая бы использовала остальные 4995 запросов.

    Многие API используют заголовки Link . Они делают API более описательными и простыми в использования. GitHub используют пагинацию в своем API, например:

    Requests автоматически парсит эти ссылки и позволяет с легкостью их использовать.

    Пользовательские HTTP-методы

    Иногда вы будете работать с сервером, который по какой-то причине требует использовать методы HTTP за исключение базовых. Например, метод MKCOL, который используют сервера WEBDAV. Однако с ними также можно работать в Requests. В данном случае используется встроенный метод .request . Например:

    Таким образом можно использовать любой метод, разрешенный сервером.

    Transport Adapters

    Начиная с версии v1.0.0, Requests использует внутренний модульный дизайн. Одна из причин — внедрение Transport Adapters. Они предоставляют средство для определения методов взаимодействия с HTTP. В частности, позволяют применять настройку для каждого сервиса по отдельности.

    Requests поставляются с одним таким Transport Adapter — HTTPAdapter . Он предоставляет возможность взаимодействия с HTTP и HTTPS посредством библиотеки urllib3 из Requests по умолчанию. При инициализации Session один из них «крепится» к объекту Session HTTP, а второй — к HTTPS.

    Requests дают возможность пользователям создавать и использовать собственные Transport Adapters с конкретной функциональностью. После создания Transport Adapter может быть прикреплен к объему Session вместе с указанием сервисов, к которым он должен применяться.

    Вызов mount регистрирует экземпляр Transport Adapter в префиксе. После этого HTTP-запросы, сделанные с помощью этого Session и URL которых начинается с этого префикса, будут использовать указанный Transport Adapter.

    Многие подробности использования Transport Adapter лежат за рамками этого материала, но вы сможете разобраться лучше на следующем примере.

    Пример: конкретная версия SSL

    Разработчики Requests заранее определили, какая версия SSL будет использоваться по умолчанию в urllib3 . Обычно это работает так, как нужно, но иногда требуется подключиться к конечной точке, которая использует версию, не совместимую с той, что указана по умолчанию.

    В этом случае можно задействовать Transport Adapter, используя большую часть существующей реализации HTTPAdapter и добавив параметр ssl_version , который передается через urllib3 . Настроим Transport Adapter, чтобы библиотека использовала SSLv3 :

    Блокирующий или не-блокирующий

    С Transport Adapter по умолчанию Requests не предоставляет никакого не-блокирующего IO (ввода-вывода). Свойство Response.content будет блокировать до тех пор, пока весь ответ не загрузится. Если требуется большая детализация, потоковые возможности библиотеки позволяют получать маленькие порции ответа в определенное время. Но и эти вызовы будут блокироваться.

    Если не хочется использовать блокировку IO, есть масса проектов, совмещающих Requests с одним из асинхронных фреймворков Python. Например, requests-threads, grequests, requests-futures и requests-async.

    Порядок заголовков

    В необычных обстоятельствах может понадобится предоставить заголовки в определенном порядке. Если передать OrderedDict в headers , это и будет обозначенный порядок. Но порядок заголовков по умолчанию в Requests будет иметь более высокий приоритет, поэтому если их перезаписать в headers , они могут отображаться беспорядочно в сравнении с теми, что указаны в аргументе.

    Чтобы решить эту проблему, необходимо настроить заголовки по умолчанию для объекта Session , предоставив ему OrderedDict . Этот порядок и станет приоритетным.

    Таймауты

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

    connect — это количество секунд, которые Requests будет выжидать для настройки соединения с вызовом удаленной машины (соответствующей connect() ) в сокете. Хорошей практикой считается настраивать это время чуть больше значения кратного 3, что является стандартным окном ретрансляции пакета TCP.

    Когда клиент подключился к серверу и отправил HTTP-запрос, таймаут read — это количество секунд, которые клиент будет ждать ответа от сервера. (Если точнее, это то количество секунд, которое клиент прождет между отправкой байтов с сервера. В 99,9% случаев оно меньше того времени с момента, когда сервер отправляет первый байт).

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

    Оно будет применено к таймауту connect и read . Если нужны отдельные значения, стоит определить их в кортеже:

    Если сервер очень медленный, можно указать Requests, чтобы он ждал вечно, передав значение None .

    Источник

    Оцените статью