Python HTTP proxy ၏ POST ကိုယ်ထည်များကို rfile တွင် buffer လုပ်နိုင်သည်
socket buffer မှ ထွက်သွားပြီးသော byte များကို စောင့်မည့်အစား handler ၏ buffer လုပ်ထားသော input မှတစ်ဆင့် Python HTTP proxy တောင်းဆိုချက်ကို ဖတ်ပါ။
Forward proxy သည် တောင်းဆိုချက်လိုင်းနှင့် header များကို ဖတ်ပြီး ပို့ဆောင်ကာ ထို့နောက် select တွင် POST ကိုယ်ထည်ကို စောင့်သည်။ client က ၎င်းကို ပို့ပြီးဖြစ်သည်။ နှစ်ဖက်စလုံး တစ်ဖက်နှင့်တစ်ဖက် စောင့်နေပုံရသည်။
Python ၏ BaseHTTPRequestHandler တွင် header ဖတ်ခြင်းသည် rfile မှတစ်ဆင့် သွားသည်၊ ၎င်းသည် buffer လုပ်ထားသော input stream ဖြစ်သည်။ ထို stream သည် ရှေ့သို့ ဖတ်နိုင်ပြီး ကိုယ်ထည်နှင့် သက်ဆိုင်သော byte များကို ကိုင်ထားနိုင်သည်။ အောက်ခံ socket ကို စောင့်ခြင်းသည် ၎င်း၏ file descriptor အသင့်ဖြစ်ခြင်း ရှိ/မရှိကိုသာ မေးသည်၊ Python stream တွင် အသုံးပြုနိုင်သော data ရှိပြီးလားဟု မမေးပါ။
header များကို ဖတ်ခဲ့သော buffer ကို လိုက်ပါ
ကိုယ်ထည်ကိုလည်း self.rfile မှတစ်ဆင့် ဖတ်ပါ။ buffer လုပ်ထားသော stream ဖြင့် header များကို ခွဲခြမ်းပြီးနောက် self.connection.recv သို့ မပြောင်းပါနှင့်။ သို့မဟုတ်ပါက ကုဒ်သည် ထို stream ကိုင်ထားသော byte များကို ကျော်ပြီး နောက်တစ်ခါ ပို့မည်မဟုတ်သော data ကို စောင့်နိုင်သည်။
rfile ကိုယ်တိုင်ကို select သို့ ပေးခြင်းသည် select က ၎င်း၏ Python buffer ကို စစ်ဆေးစေမည် မဟုတ်ပါ။ အသင့်ဖြစ်မှု API သည် object ၏ file descriptor မှတစ်ဆင့် အလုပ်လုပ်သည်။
တရားဝင် Content-Length တစ်ခုရှိပြီး Transfer-Encoding မရှိသော တောင်းဆိုချက်အတွက် ကြေညာထားသော byte အရေအတွက်ကို အတိအကျ သုံးစွဲပါ၊ input အစောပိုင်းကုန်ဆုံးခြင်းနှင့် သင့်အရွယ်အစားနှင့် အချိန်ကန့်သတ်ချက်များကို ကိုင်တွယ်ပါ။ EOF အထိ မဖတ်ပါနှင့်: တည်မြဲသော ချိတ်ဆက်မှုကို အသုံးပြုသော client သည် တောင်းဆိုချက် ပြီးဆုံးပြီးနောက်လည်း ချိတ်ဆက်မှုကို ဖွင့်ထားနိုင်သည်။
Framing ကို proxy ၏ ထင်ရှားသော အစိတ်အပိုင်းဖြစ်စေပါ
Chunked တောင်းဆိုချက် ကိုယ်ထည်များအတွက် chunked framing ပံ့ပိုးမှု လိုအပ်သည်။ မရှိသော Content-Length ကို ရှာ၍ ၎င်းတို့ကို ဖတ်၍ မရပါ။ မရှင်းလင်းသော အရှည် metadata အတွက် အဆင်ပြေဟန်တူသော header ကို ရွေးမည့်အစား သတ်မှတ်ထားသော ငြင်းပယ်မှုလမ်းကြောင်း လိုအပ်သည်။
Blocking handler သည် ကန့်သတ်ထားသော ဖတ်ခြင်းများဖြင့် ၎င်း၏ stream interface ကို ဆက်သုံးနိုင်သည်။ Event-driven proxy သည် parser ၏ ရှေ့ဖတ်ခြင်းကို အသင့်ဖြစ်မှု ကိုင်တွယ်ခြင်းနှင့် ပေါင်းစပ်သော buffer မော်ဒယ် လိုအပ်သည်။ Timeout ပြောင်းခြင်းသည် တူညီသော socket ၏ လွတ်လပ်သော သုံးစွဲသူ နှစ်ဦးကို သင့်တင့်စေမည် မဟုတ်ပါ။
ဤရောဂါရှာဖွေမှုသည် အဝင်လာသော byte များကို ဘယ်နေရာတွင် ကိုင်ထားသည်ကို အထူးရည်ညွှန်းသည်။ proxy သည် မှန်ကန်သော ကိုယ်ထည်ကို သုံးစွဲပြီးနောက်တွင်လည်း ထို ကိုယ်ထည်ကို တသမတ်တည်း HTTP framing ဖြင့် ပို့ဆောင်ရန် လိုအပ်သည်။ စံ http.server handler သည် ယန္တရားကို နားလည်ရန် အသုံးဝင်သော နေရာဖြစ်သော်လည်း ၎င်းသည် ထုတ်လုပ်မှု forward-proxy အကောင်အထည်ဖော်မှု မဟုတ်ပါ။