የNode.js CONNECT አስተናጋጆች የhead ቋትን መጠበቅ አለባቸው

የNode HTTP አገልጋይ የተለመደ የፕሮክሲ ጥያቄን በጥያቄ መልሶ ጥሪው ያስተናግዳል። CONNECT ግን ሌላ መንገድ ይወስዳል፦ አገልጋዩ connect ከጥያቄው፣ ከደንበኛው ሶኬት እና ከhead ቋት ጋር ያወጣል።

ያ ክስተት በHTTP ትንተና እና በወንፊት መካከል ያለው ሽግግር ነው። ለወንፊቱ ትራፊክ መጠቀሙን የሚቀጥል የተለመደ ServerResponse ነገር የለም።

ባይቶችን ከማስተላለፍ በፊት የHTTP ውሳኔውን ጨርሱ

የተጠየቀውን አስተናጋጅ እና ወደብ ያረጋግጡ፣ የፕሮክሲውን የመዳረሻ እና የማረጋገጫ ፖሊሲ ይተግብሩ፣ እና የላይኛውን ግንኙነት ይመስርቱ። CONNECT እንደ service.example:443 ያለ ባለስልጣን ይለያል፤ ያንን ቅርጽ የIPv6 ባለስልጣኖችን ከግምት ውስጥ በማስገባት ይተንትኑ እንጂ በእያንዳንዱ ኮሎን ላይ በዓይነ ስውር አይከፋፍሉ።

ወንፊቱ ሲቀበል፣ የተሳካውን የHTTP ምላሽ ከሚያጠግበው ባዶ መስመር ጋር ይላኩ። ከዚያ ከደንበኛው ሶኬት በሚመጡ ተከታይ ባይቶች ከመቀጠልዎ በፊት ማንኛውንም የhead ባይቶች ወደ ላይኛው ያስተላልፉ። አዲስ የውሂብ አድማጭ ማያያዝ ለአስተናጋጁ ለብቻው የደረሰ ቋትን መመለስ አይችልም።

የNode ይፋዊው የወንፊት ምሳሌ ያንን ሽግግር ሁለቱን የጅረት አቅጣጫዎች ከመገናኘቱ በፊት በserverSocket.write(head) ያከናውናል። ትንሹ ምሳሌው ሽግግሩን ያሳያል፤ የተሰማራ ፕሮክሲ ግን የተወሰነ የግንኙነት ሙከራ፣ የመዳረሻ ቁጥጥሮች እና የሕይወት ዑደት አያያዝም ይፈልጋል።

ከስኬት በኋላ ባይቶቹ የአገልግሎቱ ፕሮቶኮል ይሆናሉ

የተሳካ የCONNECT ምላሽ ግንኙነቱን ወደ ባይት ጅረት ይለውጣል። ግቡ የHTTPS ጣቢያ ከሆነ፣ የTLS ልውውጡ በዚያ ጅረት ውስጥ ይጓዛል። በቀላሉ ወንፊት ማድረጉ ፕሮክሲው ምትክ የድረገጽ ሰርተፊኬት እንዲያወጣ አይጠይቅም።

CONNECT ከመቀበሉ በፊት የHTTP ስህተት ለምን እንደተከለከለ ማሳየት ይችላል። ከተቀበለ በኋላ ግን HTTP 500 በጅረቱ ውስጥ መጻፍ ባይቶችን ወደ ወንፊቱ ፕሮቶኮል ያስገባል። በምትኩ በኋላ በሚፈጠሩ ውድቀቶች ተገቢውን ግንኙነቶች ያቁሙ ወይም ያጥፉ።

ሁለቱንም አቅጣጫዎች በየጀርባ ግፊት ግንዛቤ ያለው የጅረት አያያዝ ያገናኙ፣ እና የend፣ error እና close ክስተቶች አጋሩን እንዴት እንደሚያበቁ ይወስኑ። የመጀመሪያውን የhead ቋት የዚያው የባለቤትነት ሞዴል አካል አድርገው ይጠብቁ፤ እሱ የመተግበሪያ ውሂብ ነው፣ መጣል የሚገባው ትርፍ HTTP ራስጌ አይደለም።