ប្រសិនបើ Requests បានពន្លាតតួរួចហើយ ការបញ្ជូនវាបន្តជាមួយ Content-Encoding: gzip ស្នើឱ្យអតិថិជនបន្ទាប់ពន្លាតវាម្តងទៀត។ សម្រេចថាតើ proxy បញ្ជូនតំណាង payload មួយណាមុនពេលចម្លងក្បាលរបស់វា។

Payload ដែលបានផ្ញើcontent headers
បៃអ៊ិនកូដដើមរក្សាការអ៊ិនកូដដែលអនុវត្ត និងប្រវែង payload ពិតប្រាកដ
បៃឌិកូដដកការអ៊ិនកូដដែលបានឌិកូដចេញ; ដក ឬគណនាឡើងវិញនូវប្រវែងដែលត្រូវគ្នា

សម្រាប់បៃ payload ដែលបានអ៊ិនកូដ បំណែកនេះអានស្ទ្រីមឆៅរបស់ urllib3 ដោយគ្មានការឌិកូដ content:

with requests.get(url, stream=True, timeout=(5, 30)) as upstream:
    upstream.raise_for_status()
    for block in upstream.raw.stream(65536, decode_content=False):
        downstream.write(block)

downstream គឺជាលទ្ធផលឆ្លើយតបដែលមានស្រាប់។ ស្ថានភាព និងក្បាលរបស់វាត្រូវតែអនុវត្តតាមគោលនយោបាយដែលបានជ្រើសរើសរួចហើយ; បំណែកនេះមិនអនុវត្តម៉ាស៊ីនមេ proxy ពេញលេញទេ។

ការធ្វើស៊ុមដឹកជញ្ជូនដាច់ដោយឡែកពីការអ៊ិនកូដ content gzip។ បណ្ណាល័យ HTTP ខាងលើបានដោះស្រាយការធ្វើស៊ុមរួចហើយ រួមទាំងការដកបំណែកចេញ ដូច្នេះកុំចម្លង Transfer-Encoding ដោយភ្នែកបិទ។ ម៉ាស៊ីនមេខាងក្រោមធ្វើស៊ុមការឆ្លើយតបរបស់ខ្លួន ទោះបីជា payload នៅតែត្រូវបានអ៊ិនកូដដោយ gzip។

response.text បន្ទាប់មកដោយការអ៊ិនកូដ UTF-8 ក៏ផ្លាស់ប្តូរតំណាង និងមិនអាចរក្សាទិន្នន័យគោលពីរតាមអំពើចិត្តបានទេ។ បិទ ឬប្រើប្រាស់ការឆ្លើយតបខាងលើនៅគ្រប់ផ្លូវ ហើយដោះស្រាយកំហុស HTTP តាមកិច្ចសន្យា proxy: ឧទាហរណ៍នេះបោះពួកវាជំនួសឱ្យការបញ្ជូនបន្ត។

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