ក្នុង Requests-HTML 0.10.0 session.get() ប្រើ Requests ខណៈ response.html.render() ចាប់ផ្ដើម Pyppeteer ហើយជាធម្មតានាំ Chromium ទៅ URL ទំព័រម្ដងទៀត។ ការឆ្លើយតបដំបូងជោគជ័យមិនបង្កើតផ្លូវរបស់កម្មវិធីរុករកទេ។

សម្រាប់បរិស្ថានចាស់ដែលអាចប្រើបានដែលមានស្រាប់ ហើយប្រើ proxy 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()

ក្នុងឧទាហរណ៍ទំព័រសាធារណៈ បញ្ជី proxy HTTP ផ្ដល់បេក្ខជនសម្រាប់ proxy_url។ browser_args គឺជាការបញ្ចូល constructor សាធារណៈរបស់ session។ វចនានុក្រម proxies របស់ Requests មិនបំពេញ argument Chromium ទាំងនោះទេ។

ការសរសេរ socks5h:// របស់ Requests ក៏មិនអាចចម្លងទៅ Chromium ដោយផ្ទាល់បានដែរ។ Chromium ទទួលយក socks5:// ដោះស្រាយឈ្មោះគោលដៅ SOCKS5 តាមរយៈ proxy ហើយមិនគាំទ្រការផ្ទៀងផ្ទាត់ឈ្មោះអ្នកប្រើ/ពាក្យសម្ងាត់ SOCKS5 ទេ។

render(reload=False) ផ្ដល់ HTML ដែលមានស្រាប់ទៅកម្មវិធីរុករក ជំនួសឱ្យការនាំទៅ URL ទំព័រ។ ស្គ្រីប និងធនធានរងនៅតែអាចធ្វើសំណើបាន។ វាមានប្រយោជន៍នៅពេលគេចង់បង្ហាញការឆ្លើយតបនោះដោយចេតនា ប៉ុន្តែវាមិនបំប្លែងការតភ្ជាប់ Requests ទៅជាការដឹកជញ្ជូនរបស់កម្មវិធីរុករកទេ។

អត្ថបទពាក់ព័ន្ធ