Python HTTP પ્રોક્સીના POST બોડી rfile માં બફર કરી શકાય છે

ફોરવર્ડ પ્રોક્સી વિનંતી લાઇન અને હેડર્સ વાંચે છે, તેમને મોકલે છે, પછી select માં POST બોડીની રાહ જુએ છે. ક્લાયન્ટ તેને પહેલેથી મોકલી દીધી છે. બંને બાજુ એકબીજાની રાહ જોતી લાગે છે.

Python ના BaseHTTPRequestHandler સાથે, હેડર્સ વાંચવું rfile દ્વારા થાય છે, જે બફર કરેલો ઇનપુટ સ્ટ્રીમ છે. તે સ્ટ્રીમ આગળ વાંચી શકે છે અને બોડીના બાઇટ્સ રાખી શકે છે. અંદરના socket પર રાહ જોવી ફક્ત એ પૂછે છે કે તેનો ફાઇલ ડિસ્ક્રિપ્ટર તૈયાર છે કે નહીં; તે એ નથી પૂછતું કે Python સ્ટ્રીમમાં પહેલેથી ઉપયોગી ડેટા છે કે નહીં.

હેડર્સ વાંચનારા બફરને અનુસરો

બોડી પણ self.rfile દ્વારા વાંચો. બફર કરેલા સ્ટ્રીમ સાથે હેડર્સ પાર્સ કર્યા પછી self.connection.recv પર જશો નહીં. નહીં તો કોડ તે સ્ટ્રીમમાં રહેલા બાઇટ્સને ટાળી શકે છે અને એવા ડેટાની રાહ જોઈ શકે છે જે ફરી ક્યારેય મોકલાશે નહીં.

rfile ને જ select ને આપવાથી select તેનું Python બફર તપાસતું નથી. તૈયારી API ઑબ્જેક્ટના ફાઇલ ડિસ્ક્રિપ્ટર દ્વારા કામ કરે છે.

એક માન્ય Content-Length ધરાવતી અને Transfer-Encoding વગરની વિનંતી માટે, જાહેર કરેલા બાઇટ્સની સંખ્યા બરાબર વાપરો, સમય પહેલાં ઇનપુટ પૂરો થવો અને તમારી સાઇઝ તથા સમય મર્યાદા સંભાળો. EOF સુધી ન વાંચો: સ્થાયી કનેક્શન વાપરતો ક્લાયન્ટ વિનંતી પૂરી થયા પછી પણ કનેક્શન ખુલ્લું રાખી શકે છે.

ફ્રેમિંગને પ્રોક્સીનો સ્પષ્ટ ભાગ બનાવો

ચંક્ડ વિનંતી બોડીને ચંક્ડ ફ્રેમિંગ સપોર્ટ જોઈએ. ગેરહાજર Content-Length શોધીને તેમને વાંચી શકાતા નથી. અસ્પષ્ટ લંબાઈ મેટાડેટાને નિશ્ચિત અસ્વીકાર માર્ગ જોઈએ, અનુકૂળ લાગતું હેડર પસંદ કરવાને બદલે.

બ્લોકિંગ handler મર્યાદિત વાંચન સાથે તેના સ્ટ્રીમ ઇન્ટરફેસનો ઉપયોગ ચાલુ રાખી શકે છે. ઇવેન્ટ-ચાલિત પ્રોક્સીને એવું બફર મોડેલ જોઈએ જે પાર્સરના આગળ-વાંચનને તૈયારી સંચાલન સાથે જોડે. ટાઇમઆઉટ બદલવાથી એક જ socketના બે સ્વતંત્ર ગ્રાહકોનું સમાધાન નહીં થાય.

આ નિદાન એ વિશે છે કે આવતા બાઇટ્સ ક્યાં રાખવામાં આવે છે. પ્રોક્સીએ યોગ્ય બોડી વાપરી લીધા પછી પણ તે બોડી સુસંગત HTTP ફ્રેમિંગ સાથે મોકલવી પડે છે. પ્રમાણભૂત http.server handler મિકેનિઝમ સમજવા માટે ઉપયોગી જગ્યા છે, પણ તે ઉત્પાદન ફોરવર્ડ-પ્રોક્સી અમલીકરણ નથી.