અપલોડને ટુકડાઓમાં વાંચવા માટે chunked HTTPની જરૂર નથી

ના. ક્લાયંટ મોટી ફાઇલને નાના બફરમાં વાંચી શકે છે અને જાણીતા Content-Length સાથે મોકલી શકે છે. મર્યાદિત વાંચન મેમરીના ઉપયોગને નિયંત્રિત કરે છે; HTTP ફ્રેમિંગ રીસીવરને જણાવે છે કે વિનંતીનું બોડી ક્યાં પૂરું થાય છે.

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

HTTP/1.1 માટે, પ્રોટોકોલના નિયમો અનુસાર ખરેખર મોકલાયેલ ફ્રેમિંગ તપાસો: Content-Length અથવા chunked ટ્રાન્સફર કોડિંગ. Chunked કોડિંગ ફાઇલની સામગ્રીની બહાર માપના ચિહ્નો ઉમેરે છે. વિરોધાભાસી ફ્રેમિંગ ફીલ્ડ ભેગા ન કરો અને પ્રોક્સીને અપલોડ સ્વીકારવા મનાવવા માટે લંબાઈનો અંદાજ ન કરો.

જો પ્રોક્સી દ્વારા અપલોડ નિષ્ફળ જાય, તો HTTP આવૃત્તિ, બોડીનો સ્રોત અને પ્રથમ અસ્વીકાર નોંધો. 411 પ્રતિસાદ બોડીની વચ્ચે જોડાણ બંધ થવાથી અલગ તપાસ સૂચવે છે. જો તેના બદલે પ્રમાણીકરણની ફરી પ્રયત્નો નિષ્ફળ જાય, તો તપાસો શું અપલોડ બોડી ફરી ચલાવી શકાય. એપ્લિકેશનના રીડ-બફરનું માપ બદલવાથી વિનંતીનું ફ્રેમિંગ પહેલાં જેવું જ રહી શકે છે.

તે અવલોકન માટે માર્ગ મહત્વપૂર્ણ છે. પ્લેઇનટેક્સ્ટ ફોરવર્ડિંગ અપલોડનું HTTP ફ્રેમિંગ પ્રોક્સી સામે ખુલ્લું કરે છે; સામાન્ય એન્ડ-ટુ-એન્ડ HTTPS તેને ટનલની અંદર મૂકે છે. HTTP/2 પોતાનું ફ્રેમિંગ વાપરે છે. તેથી ઐતિહાસિક Squid મર્યાદાઓ ચોક્કસ જૂની નિષ્ફળતાઓ સમજાવે છે, એ નિયમ નહીં કે આજનું દરેક પ્રોક્સી સ્ટ્રીમ્ડ અપલોડ નકારે છે.