အောင်မြင်သော CONNECT တုံ့ပြန်မှုတွင် HTTP ကိုယ်ထည် မရှိပါ
အောင်မြင်သော HTTP/1.1 CONNECT တုံ့ပြန်မှုကို ခေါင်းစီးနယ်နိမိတ်တွင် အဆုံးသတ်ပြီး ထို့နောက် chunk framing သို့မဟုတ် ချိတ်ဆက်မှု ပြန်စတင်ခြင်းမရှိဘဲ tunnel ဘိုက်များကို ပို့ဆောင်ပါ။
အောင်မြင်သော HTTP/1.1 CONNECT တုံ့ပြန်မှုသည် ၎င်း၏ ခေါင်းစီးအပိုင်းပြီးနောက် အဆုံးသတ်သည်။
HTTP/1.1 200 Connection Established
ထိုနယ်နိမိတ်ပြီးနောက် ထိုချိတ်ဆက်မှုကပင် tunnel ကို သယ်ဆောင်သည်။ HTTPS ဦးတည်ရာအတွက် နောက်လာမည့် client ဘိုက်များသည် များသောအားဖြင့် ဦးတည်ရာနှင့် TLS ဖလှယ်မှုကို စတင်သည်။
ပရောက်စီသည် အောင်မြင်သော CONNECT တုံ့ပြန်မှုတွင် Transfer-Encoding သို့မဟုတ် Content-Length ကို ထည့်သွင်းရမည် မဟုတ်ပါ။ chunk အဖြစ် ခွဲရန် HTTP တုံ့ပြန်မှု ကိုယ်ထည် မရှိပါ။ အလွတ် အဆုံးသတ် chunk ကို ထပ်ထည့်ပါက အစား tunnel အသစ်ထဲသို့ ဘိုက်များ ထည့်သွင်းမိမည်။
client တွင်လည်း လိုအပ်ချက် ရှိသည်။ 2xx CONNECT တုံ့ပြန်မှုတွင် ထို framing အကွက်များ ပေါ်လာပါက လျစ်လျူရှုရမည်။ ထို့ကြောင့် ပုံသဏ္ဌာန်မမှန်သော ပို့သူသည် လိုက်နာသော client တိုင်းကို ခွဲထားသော ကိုယ်ထည်ကို စောင့်နေသည်ဟု ဖော်ပြရန် အကြောင်းရင်း မဟုတ်ပါ။
ထူထောင်ပြီးသော ချိတ်ဆက်မှုကို ထပ်ဆင့်ပို့ရန် ဖွင့်ထားပါ။ 200 ပြီးနောက် ၎င်းကို ပိတ်ပါက tunnel ပျက်စီးသည်။ အခြား ချိတ်ဆက်မှု ဖွင့်ခြင်းသည် လက်ခံထားသော CONNECT တောင်းဆိုမှု၏ အဆက်မဟုတ်ပါ။
မအောင်မြင်သော CONNECT တုံ့ပြန်မှုကို ကွဲပြားစွာ ကိုင်တွယ်ပြီး သာမန် HTTP အမှား ကိုယ်ထည် ပါနိုင်သည်။ ပရောက်စီ ခြေရာကို အကောင်အထည်ဖော်ခြင်း သို့မဟုတ် ဖတ်ခြင်းတွင် ထို တုံ့ပြန်မှုကို အောင်မြင်သော လွှဲပြောင်းမှုနှင့် ခွဲခြားပါ။