Requests proxy не работает

Python-сообщество

Уведомления

#1 Сен. 20, 2013 15:58:43

Не работает модуль python requests через прокси по https-протоколу

Здравствуйте, уважаемые программисты на python.

Только начал изучать python, пишу небольшой скрипт для работы с твиттером с использованием прокси…

Не могу заставить модуль python requests работать через прокси по https.
С офсайта этого модуля:

If you need to use a proxy, you can configure individual requests with the proxies argument to any request method:

Но проблема в том, что это почему-то не работает именно для https-протокола.

Вот для наглядности скрипт на python с использованием requests с подключением через прокси, который получает страницы сервисов по получению IP по http и по https протоколам:

То есть как видим, удается получить страницу по http и выдается ошибка при попытки получения страницы по https.
Используемый мною прокси 193.106.31.10:8085 (привязан к моему IP) точно умеет работать по https, так как аналогичный скрипт на php+curl у меня работает — то есть сервис https://ipdb.at/ успешно возвращает страницу на которой IP 193.106.31.10.

Большая просьба помочь разобраться как с помощью модуля requests работать именно по https-протоколу с использованием прокси, никакое гугление вот уже несколько суток ничего не дает, надежда только на форум.

Отредактировано valet (Сен. 20, 2013 15:59:29)

Источник

Модуль request не соединяется через HTTPS прокси

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

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

Прокси через request или grab
Нужно как-то подключить прокси к моему проекту . Можно как добавлением переменной , так и парсингом.

Протокол https и работа через sock4-5 прокси
Доброго дня. До сегодняшнего дня работал с классами httpwebrequest\response и http прокси, но.

Как передать GET-запрос по HTTPS через прокси-сервер?
Пытаясь работать с прокси-сервером столкнулся с проблемой. Открываю сокет между своим сервером и.

Через JavaScript соединяется с SQL, а через VBScript не хочет!
Вот такая штука работает нормально: 1

zoom59rus, Проблема была, но ни как не связанная с прокси и requests, только твое неправильное использование библиотеки.

Https to http прокси
Ситуация следующая, хотелось бы поднять прокси, который обращается к серверу по https, а с клиентом.

Aiohttp с https прокси
При выполнении данного кода происходит ошибка: ValueError: Only http proxies are supported .

XNet, прокси с авторизацией и https
Доброго времени суток. Столкнулся с проблемой при использование библиотеки xNet с проксями с.

Сайты на https и бесплатные прокси
Здравствуйте. Часто захожу через бесплатные прокси в ВК и Яндекс Почту, стоит ли опасаться.

Прозрачный прокси squid3 и https
Всем хорошего дня. Вообщем настраиваю на debian7 squid3 прозрачный наткнулся на проблему с https, .

Источник

Как обойти ошибку SSL и прокси-сервера запросов Python?

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

Ошибка requests.exceptions.SSLError

Итак, я устал verify = False в качестве одного из параметров request.get (), но затем получаю ошибку request.exceptions.ProxyError, которую вы можете увидеть ниже:

Request.exceptions.ProxyError

Я устал искать каждый ответ, но, похоже, ничего не работает. Не могу отправить запрос через прокси с аутентификацией. Есть идеи?

1 ответ

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

Судя по ссылке на _connect_tls_proxy в трассировке стека, eampleIpWithAuth очень вероятно что-то вроде https://. , т.е. вы пытаетесь получить доступ к самому прокси через HTTPS. Обратите внимание, что доступ к прокси-серверу через HTTPS отличается от использования прокси-сервера HTTP для HTTPS. При доступе к URL-адресу HTTPS через прокси-сервер HTTPS, по сути, выполняется двойное шифрование прокси-сервера:

В то время как с URL-адресом HTTPS поверх «обычного» HTTP-прокси используется только одно шифрование, т.е. оно выглядит (упрощенно) следующим образом:

Скорее всего, вы хотите использовать обычный HTTP-прокси, а не HTTPS-прокси. На самом деле это самый частый случай.

Источник

Продвинутое руководство по библиотеке 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 запросов.

Заголовки Link

Многие 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 .

Источник