જ્યારે ડાઉનલોડ કરેલી ફાઇલ HTTP સ્થિતિ લાઇનથી શરૂ થાય

જો કોઈ કથિત PDF કે સ્પ્રેડશીટ HTTP/1.1 200 OK થી શરૂ થાય, તો ડાઉનલોડરે ફાઇલને બદલે કાચો પ્રતિસાદ સાચવ્યો છે. આ યોજનાકીય પ્રતિસાદમાં ફક્ત ચાર બાઇટ સામગ્રી છે:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

ફાઇલ DATA છે. સ્થિતિ લાઇન, હેડર, માપ નિશાન અને અંતિમ બંધારણ HTTP ના છે. નિશ્ચિત સંખ્યામાં બાઇટ દૂર કરવા સુરક્ષિત નથી કારણ કે હેડરની લંબાઈ બદલાય છે. પ્રથમ ખાલી લાઇન પછીનું બધું કૉપી કરવાથી પણ ચંક ફ્રેમિંગ રહી જાય છે, અને માહિતીપ્રદ પ્રતિસાદ અંતિમ પ્રતિસાદ પહેલાં આવી શકે છે.

સામાન્ય ડાઉનલોડ માટે, કાચા સોકેટથી ફાઇલમાં કૉપી કરવાને બદલે HTTP ક્લાયન્ટના પ્રતિસાદ-બોડી ઇન્ટરફેસનો ઉપયોગ કરો. તેનો પ્રોક્સી ગોઠવો, અંતિમ સ્થિતિ માન્ય કરો અને બોડીને કામચલાઉ આઉટપુટમાં સ્ટ્રીમ કરો. ક્લાયન્ટ સંદેશ ફ્રેમિંગ સંભાળે છે: લંબાઈ-મર્યાદિત, ચંક કરેલા અને જોડાણ-મર્યાદિત બોડીને જુદા જુદા પાર્સિંગની જરૂર પડે છે.

સામગ્રી એન્કોડિંગ બીજું સ્તર છે. ક્લાયન્ટના દસ્તાવેજીકૃત વર્તનના આધારે નક્કી કરો કે તમને ડિકોડ કરેલા ફાઇલ બાઇટની જરૂર છે કે સ્પષ્ટ રીતે વિનંતી કરેલી કાચી સામગ્રીની. સંકુચિત બાઇટ આપોઆપ પ્રોક્સી ભ્રષ્ટાચાર નથી.

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

HTTPS ને CONNECT પ્રતિસાદ કાઢી નાખવાથી વધુ જરૂર છે: ટનલ સફળતાપૂર્વક સ્થાપિત થયા પછી લક્ષ્યનું TLS સ્થાપિત કરો અને પછી અંદરનો HTTP પ્રતિસાદ પાર્સ કરો. પ્રોક્સીના હેડર પછીના એન્ક્રિપ્ટેડ બાઇટ ડાઉનલોડ કરી શકાય તેવી ફાઇલ નથી.

નિષ્ફળ કે અપૂર્ણ આઉટપુટને કામચલાઉ નામ હેઠળ રાખો. સ્થાનાંતરણ અને ફાઇલ ચકાસણી સફળ થાય પછી જ તેને પ્રકાશિત કરો; ખાલી ન હોય તેવી ફાઇલ સંપૂર્ણ ડાઉનલોડ સાબિત કરતી નથી.