Requests-HTML 0.10.0: i-configure ang Chromium proxy para sa render()
I-configure ang mga argumento sa paglulunsad ng Chromium at pati na ang Requests kapag ang lumang pahina ng Requests-HTML ay nagtagumpay bago ang render() at nabigo pagkatapos.
Sa Requests-HTML 0.10.0, gumagamit ang session.get() ng Requests, habang ang response.html.render() ay naglulunsad ng Pyppeteer at karaniwang dinadala muli ang Chromium sa URL ng pahina. Ang matagumpay na unang tugon ay hindi nagtatatag ng ruta ng browser.
Para sa isang umiiral na katugmang lumang kapaligiran na gumagamit ng HTTP proxy na walang pagpapatunay:
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()
Sa halimbawa ng pampublikong pahina, ang listahan ng HTTP proxy ay nagbibigay ng mga kandidato para sa proxy_url. Ang browser_args ay ang pampublikong input ng constructor ng session. Ang diksyunaryo na proxies ng Requests ay hindi pinupuno ang mga argumentong iyon ng Chromium.
Ang baybay na socks5h:// ng Requests ay hindi rin basta makokopya sa Chromium. Tumatanggap ang Chromium ng socks5://, nilulutas ang mga pangalan ng destinasyon ng SOCKS5 sa pamamagitan ng proxy, at hindi sinusuportahan ang pagpapatunay ng SOCKS5 sa username/password.
Ipinapasa ng render(reload=False) ang umiiral na HTML sa browser sa halip na mag-navigate sa URL ng pahina. Ang mga script at sub-resource ay maaari pa ring gumawa ng mga kahilingan. Kapaki-pakinabang ito kapag sadyang ini-render ang tugon na iyon, ngunit hindi nito ginagawang transport ng browser ang koneksyon ng Requests.