HTTP CONNECT જવાબ પછી બફર થયેલો ડેટા સાચવો

નાનું પ્રોક્સી રેપર HTTPS માટે કામ કરી શકે છે અને પછી એવા પ્રોટોકોલ માટે ફરી વાપરવામાં આવે ત્યારે અટકી જાય છે જેમાં સર્વર પહેલા બોલે છે. શંકાસ્પદ લીટી ઘણીવાર એ હોય છે જે પ્રાપ્તિ બફર \r\n\r\n સાથે સમાપ્ત થવાની રાહ જુએ છે.

TCP ક્લાયન્ટને સ્ટ્રીમ આપે છે. એક પ્રાપ્તિ કૉલ અડધી HTTP સ્ટેટસ લાઇન, પૂરો CONNECT જવાબ, અથવા એ જવાબની તરત જ ટનલ ડેટા સાથે પરત કરી શકે છે. એવી કોઈ ખાતરી નથી કે વાંચન હેડરોના અંતે અટકે છે.

બફરની અંદર સીમા શોધો

HTTP/1.1 CONNECT વિનિમય માટે, બાઇટ્સ એકઠા કરો જ્યાં સુધી હેડર સમાપ્તિ ચિહ્ન બફરમાં ગમે ત્યાં ન દેખાય. તેની પ્રથમ આવૃત્તિ પર વિભાજિત કરો. પ્રથમ ભાગમાંથી સ્ટેટસ લાઇન અને હેડરોનું વિશ્લેષણ કરો; સીમા પછીનું બધું અલગ રાખો. રાહ જોતી વખતે હેડર કદ મર્યાદા અને સમયમર્યાદા લાગુ કરો, અને ખાલી સોકેટ વાંચનને લૂપમાં ફરવાનું બીજું આમંત્રણ ગણવાને બદલે બંધ કનેક્શન ગણો.

અંતિમ સફળ 2xx જવાબ તે હેડરો પછી તરત જ કનેક્શનને ટનલ મોડમાં બદલી નાખે છે. તેની પાછળના બાઇટ્સ પહેલેથી ટનલ બાઇટ્સ છે. તેમને ફેંકી દેશો નહીં, CONNECT જવાબ બોડીની રાહ જોશો નહીં, અને Content-Length ફીલ્ડને નવા પ્રોટોકોલનો ભાગ વાપરવાની પરવાનગી તરીકે અર્થઘટન કરશો નહીં. માહિતીપ્રદ જવાબો, જો હોય, તો તે અંતિમ જવાબ પહેલાં સંભાળવા જોઈએ.

રેપરે તેના બચેલા ભાગ આગળ પસાર કરવા જોઈએ

ફક્ત અંતર્ગત સોકેટ પરત કરવાથી હેન્ડશેક પાર્સરે તેમાંથી પહેલેથી કાઢેલા બાઇટ્સ ખોવાઈ જાય છે. આગલા વાચકને બફર કરેલો સ્ટ્રીમ જોઈએ જે પહેલા સાચવેલી પૂંછડી આપે અને પછી સોકેટ વાંચન ફરી શરૂ કરે. સર્વર-પ્રથમ પ્રોટોકોલ માટે, તે પ્રારંભિક અભિવાદન ગુમાવવાથી બંને બાજુઓ અનિશ્ચિત સમય સુધી રાહ જોઈ શકે છે.

તેનાથી વિપરીત, નિષ્ફળ CONNECT જવાબના બાઇટ્સ ટનલ અભિવાદન નથી. 407 હજી પણ પ્રોક્સી વિનિમયનું જ છે અને તેને પ્રમાણીકરણ સંભાળની જરૂર છે; બીજું અસફળ સ્ટેટસ યોગ્ય ભૂલ માર્ગની જરૂર છે.

આ ખાસ કરીને ત્યારે મહત્વનું છે જ્યારે HTTP પ્રોક્સી દ્વારા FTP અથવા SSH ક્લાયન્ટને અનુકૂલિત કરવામાં આવે. પ્રોક્સીએ વિનંતી કરેલ ગંતવ્ય પોર્ટને પણ પરવાનગી આપવી પડે છે, અને FTP ને વધારાના ડેટા કનેક્શનની જરૂર પડી શકે છે. સાચું હેડર વિશ્લેષણ સ્ટ્રીમ હસ્તાંતરણ ઉકેલે છે; તે CONNECT પરવાનગી આપી શકતું નથી કે FTPનું બીજું ચેનલ પૂરું પાડી શકતું નથી.