အပ်လုဒ်ကို အပိုင်းလိုက်ဖတ်ရန် chunked HTTP မလိုအပ်ပါ

မဟုတ်ပါ။ ကလိုင်းယင့်သည် ဖိုင်ကြီးကို ဘူဖာငယ်များဖြင့် ဖတ်ပြီး သိထားသော Content-Length ဖြင့် ပို့နိုင်သည်။ ကန့်သတ်ဖတ်ခြင်းသည် မှတ်ဉာဏ်အသုံးပြုမှုကို ထိန်းချုပ်သည်။ HTTP ဘောင်ခတ်ခြင်းက တောင်းဆိုမှု၏ ကိုယ်ထည်သည် မည်သူ့တွင် အဆုံးသတ်သည်ကို လက်ခံသူအား ပြောသည်။

HTTP စာကြည့်တိုက်က ဘိုက်အလျားကို သိထားသော တည်ငြိမ်သောဖိုင်သည် မသိသော ဒေတာပမာဏကို ထုတ်လုပ်သော ဂျင်နရေတာနှင့် မတူပါ။ ရင်းမြစ်နှစ်ခုလုံးအတွက် စာကြည့်တိုက်က ပံ့ပိုးသော ကိုယ်ထည် အင်တာဖေ့စ်ကို သုံးပါ။ အလျားပေးရန်အတွက်သာ ဖိုင်တစ်ခုလုံးကို စာသားတစ်ကြောင်းအဖြစ် စုစည်းရန် မလိုအပ်ပါ။

HTTP/1.1 အတွက်၊ ပရိုတိုကော၏ စည်းမျဉ်းများအရ အမှန်တကယ်ပို့သော ဘောင်ခတ်ခြင်းကို စစ်ဆေးပါ။ Content-Length သို့မဟုတ် chunked သယ်ယူခြင်းကုဒ်ပြုလုပ်ခြင်း ဖြစ်သည်။ Chunked ကုဒ်ပြုလုပ်ခြင်းသည် ဖိုင်အကြောင်းအရာ၏ အပြင်ဘက်တွင် အရွယ်အစား အမှတ်အသားများ ထည့်သည်။ ကွဲလွဲသော ဘောင်ခတ်ခြင်း အကွက်များကို မပေါင်းစပ်ပါနှင့်၊ ပရောက်စီက အပ်လုဒ်ကို လက်ခံစေရန် အလျားကို မခန့်မှန်းပါနှင့်။

ပရောက်စီမှတစ်ဆင့် အပ်လုဒ် မအောင်မြင်ပါက HTTP ဗားရှင်း၊ ကိုယ်ထည်ရင်းမြစ်နှင့် ပထမဆုံး ငြင်းပယ်မှုကို မှတ်တမ်းတင်ပါ။ 411 တုံ့ပြန်မှုသည် ကိုယ်ထည် အလယ်တွင် ပိတ်သွားသော ချိတ်ဆက်မှုနှင့် မတူသော စုံစမ်းစစ်ဆေးမှုကို ညွှန်ပြသည်။ အစား အတည်ပြုခြင်း ပြန်ကြိုးစားမှုများ မအောင်မြင်ပါက အပ်လုဒ် ကိုယ်ထည်ကို ပြန်ဖွင့်နိုင်သလား စစ်ဆေးပါ။ အက်ပ်၏ ဖတ်ဘူဖာအရွယ်အစားကို ပြောင်းခြင်းက တောင်းဆိုမှု ဘောင်ခတ်ခြင်းကို မူလအတိုင်း ထားရစ်နိုင်သည်။

ထိုလေ့လာတွေ့ရှိချက်အတွက် လမ်းကြောင်းသည် အရေးကြီးသည်။ ရိုးရိုးစာသားဖြင့် ပို့ဆောင်ခြင်းက အပ်လုဒ်၏ HTTP ဘောင်ခတ်ခြင်းကို ပရောက်စီထံ ဖော်ထုတ်သည်။ ပုံမှန် အစွန်းမှအစွန်း HTTPS က ၎င်းကို ဥမင်အတွင်း ထည့်ထားသည်။ HTTP/2 သည် ၎င်း၏ ကိုယ်ပိုင်ဘောင်ခတ်ခြင်းကို သုံးသည်။ ထို့ကြောင့် Squid ၏ သမိုင်းဝင်ကန့်သတ်ချက်များသည် တိကျသော ဟောင်းနွမ်းသော မအောင်မြင်မှုများကို ရှင်းပြသည်၊ ယနေ့ခေတ် ပရောက်စီတိုင်း စီးကြောင်းအပ်လုဒ်များကို ငြင်းပယ်သည်ဟူသော စည်းမျဉ်း မဟုတ်ပါ။