В Requests-HTML 0.10.0 session.get() използва Requests, докато response.html.render() стартира Pyppeteer и обикновено отново навигира Chromium към URL адреса на страницата. Успешният първи отговор не установява маршрута на браузъра.

За съществуваща съвместима стара среда с HTTP прокси без удостоверяване:

from requests_html import HTMLSession

proxy_url = 'http://proxy.example:8080'
session = HTMLSession(browser_args=[
    '--proxy-server=' + proxy_url,
])
try:
    response = session.get(
        'https://www.example.org/',
        proxies={'https': proxy_url},
        timeout=20,
    )
    response.html.render(timeout=20)
    rendered = response.html.html
finally:
    session.close()

В примера с публична страница списъкът с HTTP прокси сървъри предлага кандидати за proxy_url. browser_args е публичният вход на конструктора на сесията. Речникът proxies на Requests не попълва тези аргументи на Chromium.

Записът socks5h:// на Requests също не може просто да се копира в Chromium. Chromium приема socks5://, разрешава имената на дестинациите на SOCKS5 през проксито и не поддържа удостоверяване с потребителско име и парола за SOCKS5.

render(reload=False) подава съществуващия HTML на браузъра вместо да навигира към URL адреса на страницата. Скриптовете и подресурсите все още могат да правят заявки. Това е полезно, когато умишлено се рендира този отговор, но не превръща връзката на Requests в транспорт на браузъра.

Подобни статии