የፊት ፕሮክሲው የጥያቄውን መስመርና ራስጌዎችን አንብቦ ያስተላልፋል፣ ከዚያም በselect ውስጥ የPOST አካልን ይጠብቃል። ደንበኛው አስቀድሞ ልኮታል። ሁለቱም ወገኖች አንዱ ሌላውን እየጠበቀ ይመስላል።

በPython BaseHTTPRequestHandler ውስጥ ራስጌዎችን ማንበብ በrfile በኩል ያልፋል፣ እሱም የተቀመጠ የግብዓት ፍሰት ነው። ያ ፍሰት ወደፊት ማንበብና የአካሉ ባይቶችን መያዝ ይችላል። በስር ያለውን ሶኬት መጠበቅ የፋይል መግለጫው ዝግጁ መሆኑን ብቻ ነው የሚጠይቀው፤ የPython ፍሰቱ አስቀድሞ ጠቃሚ ውሂብ ይዟል እንደሆነ አይጠይቅም።

ራስጌዎቹን ያነበበውን ቋት ይከተሉ

አካሉንም በself.rfile በኩል ያንብቡ። ራስጌዎችን በተቀመጠው ፍሰት ካነበቡ በኋላ ወደ self.connection.recv አይቀይሩ። አለበለዚያ ኮዱ በዚያ ፍሰት የተያዙ ባይቶችን በማለፍ ወደፊት በፍጹም የማይላክ ውሂብን ሊጠብቅ ይችላል።

rfile ራሱን ለselect ማስረከብ select የPython ቋቱን እንዲመረምር አያደርግም። የዝግጁነት API በእቃው የፋይል መግለጫ በኩል ይሠራል።

አንድ ትክክለኛ Content-Length ያለውና Transfer-Encoding የሌለው ጥያቄ ሲሆን፣ የተገለጸውን የባይት ብዛት በትክክል ይጠቀሙ፣ ከጊዜ በፊት የሚያበቃ ግብዓትንና የመጠንና የጊዜ ገደቦችዎን ያስተካክሉ። እስከ EOF አያንብቡ፦ ቋሚ ግንኙነት የሚጠቀም ደንበኛ ጥያቄውን ከጨረሰ በኋላ ግንኙነቱን ክፍት ሊያስቀምጥ ይችላል።

ማዕቀፍ አደረጃጀትን የፕሮክሲው ግልጽ ክፍል ያድርጉ

የተቆራረጡ የጥያቄ አካላት የተቆራረጠ ማዕቀፍ ድጋፍ ይፈልጋሉ። የሌለውን Content-Length በመፈለግ ማንበብ አይቻልም። አሻሚ የሆነ የርዝመት መረጃ ምቹ የሚመስለውን ራስጌ ከመምረጥ ይልቅ የተወሰነ የመከልከል መንገድ ይፈልጋል።

የሚያግድ አስተናጋጅ የፍሰት በይነገጹን በተገደበ ንባብ መጠቀሙን ሊቀጥል ይችላል። በክስተት የሚመራ ፕሮክሲ የተንታኙን ቅድመ ንባብ ከዝግጁነት አያያዝ ጋር የሚያዋህድ የቋት ሞዴል ይፈልጋል። ጊዜ ገደብን መቀየር በአንድ ሶኬት ላይ ያሉ ሁለት ነጻ ተጠቃሚዎችን አያስታርቅም።

ይህ ምርመራ የሚመለከተው ገቢው ባይት የሚቀመጥበትን ቦታ ነው። ፕሮክሲው ትክክለኛውን አካል ከተጠቀመ በኋላ፣ ያንን አካል በተመሳሳይ HTTP ማዕቀፍ ማስተላለፍ አለበት። መደበኛው http.server አስተናጋጅ ስልቱን ለመረዳት ጠቃሚ ቦታ ነው፣ ግን የምርት የፊት ፕሮክሲ አተገባበር አይደለም።

ተዛማጅ ጽሑፎች