അപ്‌ലോഡ് കഷണങ്ങളായി വായിക്കാൻ chunked HTTP ആവശ്യമില്ല

ഇല്ല. ഒരു ക്ലയന്റിന് വലിയ ഫയൽ ചെറിയ ബഫറുകളിൽ വായിച്ച് അറിയപ്പെടുന്ന Content-Length-നൊപ്പം അയയ്ക്കാം. പരിമിതമായ വായനകൾ മെമ്മറി ഉപയോഗം നിയന്ത്രിക്കുന്നു; HTTP ഫ്രെയിമിംഗ് അഭ്യർത്ഥനയുടെ ബോഡി എവിടെ അവസാനിക്കുന്നു എന്ന് സ്വീകർത്താവിനോട് പറയുന്നു.

HTTP ലൈബ്രറിക്ക് ബൈറ്റ് നീളം അറിയാവുന്ന സ്ഥിരമായ ഫയൽ, അജ്ഞാതമായ അളവിൽ ഡാറ്റ ഉത്പാദിപ്പിക്കുന്ന ജനറേറ്ററിൽ നിന്ന് വ്യത്യസ്തമാണ്. രണ്ട് ഉറവിടങ്ങൾക്കും ലൈബ്രറി പിന്തുണയ്ക്കുന്ന ബോഡി ഇന്റർഫേസ് ഉപയോഗിക്കുക. നീളം നൽകാൻ മാത്രം മുഴുവൻ ഫയലും ഒരു സ്ട്രിംഗിൽ ചേർക്കേണ്ടതില്ല.

HTTP/1.1-നായി, യഥാർത്ഥത്തിൽ അയച്ച ഫ്രെയിമിംഗ് പരിശോധിക്കുക: പ്രോട്ടോക്കോളിന്റെ നിയമങ്ങൾ പ്രകാരം Content-Length അല്ലെങ്കിൽ chunked ട്രാൻസ്ഫർ കോഡിംഗ്. Chunked കോഡിംഗ് ഫയൽ ഉള്ളടക്കത്തിന് പുറത്ത് വലിപ്പ അടയാളങ്ങൾ ചേർക്കുന്നു. വൈരുദ്ധ്യമുള്ള ഫ്രെയിമിംഗ് ഫീൽഡുകൾ സംയോജിപ്പിക്കരുത്, പ്രോക്സിയെ അപ്‌ലോഡ് സ്വീകരിക്കാൻ പ്രേരിപ്പിക്കാൻ നീളം ഊഹിക്കരുത്.

പ്രോക്സിയിലൂടെയുള്ള അപ്‌ലോഡ് പരാജയപ്പെട്ടാൽ, HTTP പതിപ്പ്, ബോഡിയുടെ ഉറവിടം, ആദ്യ നിരാകരണം എന്നിവ രേഖപ്പെടുത്തുക. 411 പ്രതികരണം ബോഡിയുടെ നടുവിൽ അടയുന്ന കണക്ഷനിൽ നിന്ന് വ്യത്യസ്തമായ അന്വേഷണം സൂചിപ്പിക്കുന്നു. പകരം പ്രാമാണീകരണ വീണ്ടും ശ്രമങ്ങൾ പരാജയപ്പെട്ടാൽ, അപ്‌ലോഡ് ബോഡി വീണ്ടും പ്ലേ ചെയ്യാനാകുമോ എന്ന് പരിശോധിക്കുക. ആപ്പ്‌ലിക്കേഷന്റെ റീഡ്-ബഫർ വലിപ്പം മാറ്റുന്നത് അഭ്യർത്ഥനയുടെ ഫ്രെയിമിംഗ് മുമ്പുണ്ടായിരുന്നതുപോലെ തന്നെ വിട്ടേക്കാം.

ആ നിരീക്ഷണത്തിന് പാത പ്രധാനമാണ്. പ്ലെയിൻടെക്സ്റ്റ് ഫോർവേഡിംഗ് അപ്‌ലോഡിന്റെ HTTP ഫ്രെയിമിംഗ് പ്രോക്സിക്ക് വെളിപ്പെടുത്തുന്നു; സാധാരണ എൻഡ്-ടു-എൻഡ് HTTPS അതിനെ ഒരു ടണലിനുള്ളിൽ ഇടുന്നു. HTTP/2 സ്വന്തം ഫ്രെയിമിംഗ് ഉപയോഗിക്കുന്നു. അതിനാൽ Squid-ന്റെ ചരിത്രപരമായ പരിമിതികൾ ചില പഴയ പരാജയങ്ങൾ വിശദീകരിക്കുന്നു, ഇന്നത്തെ എല്ലാ പ്രോക്സിയും സ്ട്രീം ചെയ്ത അപ്‌ലോഡുകൾ നിരസിക്കുന്നു എന്ന നിയമമല്ല.