ပရောက်စီနောက်တွင် Requests ၏ တုံ့ပြန်မှု ပျက်နေသလို ထင်ပါသလား။ Brotli ပံ့ပိုးမှုကို စစ်ဆေးပါ

ကူးယူထားသော Accept-Encoding:br သည် hosted Requests ပတ်ဝန်းကျင်၏ ဒီကုဒ်ဒါ ပံ့ပိုးမှုကို ကျော်လွန်နိုင်သည်။

လက်တော့ပ်နှင့် hosted လုပ်ငန်းစဉ်ကို မတူညီသော အလွှာနှစ်ခုတွင် နှိုင်းယှဉ်ပါ−

အလွှာမေးခွန်း
Content-Encodingကလိုင်းယင့်သည် ပြန်ပို့လာသော gzip/deflate/Brotli ဘိုက်များကို ချေဖျက်နိုင်ပါသလား။
Charsetချေဖျက်ပြီး ဘိုက်များသည် စာသားအဖြစ် မည်သို့ပြောင်းလဲသနည်း။

Requests သည် များသောအားဖြင့် gzip/deflate ကို ကိုင်တွယ်သည်။ Brotli အတွက် ထည့်သွင်းထားသော ပံ့ပိုးသည့် လိုက်ဘရယ်ရီ လိုအပ်သည်။ ကိုယ်တိုင်ကူးယူထားသော Accept-Encoding သည် ဤပတ်ဝန်းကျင် ဒီကုဒ်မလုပ်နိုင်သော်လည်း br ကို ကြေညာနိုင်သည်။ UTF-8 စာသား ရွေးချယ်ခြင်းသည် Brotli ကို ချေဖျက်မပေးပါ။

ညှိနှိုင်းမှုကို တမင်ကန့်သတ်သည့်အခါ−

response = session.get(
    url,
    proxies={"https": "http://proxy.example:8080"},
    headers={"Accept-Encoding": "gzip, deflate"},
    timeout=30,
)
response.raise_for_status()

လက်ရှိ Session၊ HTTPS URL နှင့် လိုအပ်သော ခေါင်းစီး/အထောက်အထား စစ်ဆေးမှုကို အသုံးပြုပါ။ စက်နှစ်လုံးစလုံးတွင် ထွက်သွားသော Accept-Encoding၊ ဝင်လာသော Content-Encoding နှင့် ပက်ကေ့ဂျ် ပံ့ပိုးမှုကို နှိုင်းယှဉ်ပါ။ အသွင်ပြောင်းသော ကြားခံသည် ခေတ်မမီသော မက်တာဒေတာကိုလည်း ပေးနိုင်သည်။ သီးခြား အများပြည်သူ စာမျက်နှာ နှိုင်းယှဉ်မှုသည် အများပြည်သူ ကြားခံများ ခွင့်ပြုထားသောနေရာတွင် ၎င်း၏ ပရောက်စီ URL အတွက် HTTP ပရောက်စီ စာရင်း ကို အသုံးပြုနိုင်သည်။ သို့သော် အမွေဆက်ခံသော ပရောက်စီ အထောက်အထား၊ ကူးယူထားသော အကောင့် ခေါင်းစီး သို့မဟုတ် ကိုယ်ပိုင် body ဒေတာ မပါဘဲ။

အခြားနည်းဖြင့် ပုံမှန် ကလိုင်းယင့် ညှိနှိုင်းမှုကို ဦးစားပေးပါ။ Requests ၏ အဆင်ပြေသော content/text အင်တာဖေ့စ်များသည် ပံ့ပိုးသော ကုဒ်ပြောင်းခြင်းကို ဒီကုဒ်လုပ်သည်။ ထို့ကြောင့် ခေါင်းစီးက ၎င်း၏အမည် ဖော်ပြသည်ဟူသော အကြောင်းကြောင့်သာ ၎င်းတို့၏ ထွက်ရှိမှုကို ထပ်မံ မချေဖျက်ပါနှင့်။

ဆက်စပ်ဆောင်းပါးများ