បញ្ជូនបន្តបៃ gzip ជាមួយក្បាលដែលពិពណ៌នាពួកវា
ជ្រើសរើស payload ដែលបានអ៊ិនកូដ ឬបានឌិកូដនៅក្នុង proxy ដែលមានមូលដ្ឋានលើ Requests បន្ទាប់មកផ្តល់ឱ្យការឆ្លើយតបខាងក្រោមនូវ content headers ដែលត្រូវគ្នា និងការធ្វើស៊ុមរបស់វា។
ប្រសិនបើ 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: ឧទាហរណ៍នេះបោះពួកវាជំនួសឱ្យការបញ្ជូនបន្ត។