HTTP അപ്‌ലോഡ് താൽക്കാലിക നിർത്തലുകളും Expect: 100-continue-ഉം

കണക്ഷൻ തുറക്കുന്നു. അഭ്യർത്ഥനാ ഹെഡറുകൾ പുറപ്പെടുന്നു. ഫയൽ നീങ്ങുന്നില്ലെന്ന് തോന്നുന്നു. ഒരു വിശദീകരണം, തന്റെ ബോഡി അയയ്ക്കുന്നതിന് മുമ്പ് ക്ലയന്റ് Expect: 100-continue എന്നതിനുള്ള മറുപടിക്കായി കാത്തിരിക്കുന്നു എന്നതാണ്.

സാധ്യമായി വലിയ അപ്‌ലോഡ് അയയ്ക്കുന്നതിന് മുമ്പ്, അതിന്റെ ഹെഡറുകളിൽ നിന്ന് ഒരു അഭ്യർത്ഥന നിരസിക്കാൻ ഈ സംവിധാനം സ്വീകർത്താവിനെ അനുവദിക്കുന്നു. സാധാരണ വിജയകരമായ ക്രമം:

request headers → 100 Continue → request body → final response

100 വിവരദായകമാണ്: അത് ക്ലയന്റിന് തുടരാൻ അനുവാദം നൽകുന്നു, പക്ഷേ ഫയൽ സംഭരിച്ചു എന്നോ ആപ്ലിക്കേഷൻ പ്രവർത്തനം വിജയിച്ചു എന്നോ അർത്ഥമാക്കുന്നില്ല. HTTP 417 നൽകുന്ന Git push അത്തരം ഒരു പ്രത്യേക പ്രതീക്ഷാ-പരാജയ കേസാണ്.

ക്ലയന്റിന് ലഭിച്ച മറുപടി ഏതെന്ന് കണ്ടെത്തുക

curl-ൽ പ്രത്യേക expect-continue കാത്തിരിപ്പ് ക്രമീകരണമുണ്ട്. ആ libcurl കാത്തിരിപ്പ് പ്രതീക്ഷിച്ച മറുപടിയില്ലാതെ കാലഹരണപ്പെട്ടാൽ, ബോഡി എന്തായാലും അയയ്ക്കുന്നു; കാലഹരണം സ്വയമേവ പൂർണ്ണ കൈമാറ്റത്തിന്റെ പരാജയമല്ല. ഈ ക്രമീകരണം പൂർണ്ണ കൈമാറ്റത്തിന് അനുവദിച്ച സമയത്തിൽ നിന്ന് വേറിട്ടതാണ്. രണ്ടാമത്തേത് കൂട്ടുന്നത് അതേ പ്രാരംഭ താൽക്കാലിക നിർത്തൽ വിശദീകരിക്കപ്പെടാതെ വിട്ടേക്കാം.

ഏത് HTTP സംഭാഷണമാണ് Expect വഹിക്കുന്നതെന്നും തിരിച്ചറിയുക. HTTPS ലക്ഷ്യത്തിലേക്കുള്ള സാധാരണ CONNECT-ൽ, വെബ്‌സൈറ്റിന്റെ അപ്‌ലോഡ് കൈമാറ്റം TLS-നുള്ളിൽ ആണ്; ഫോർവേഡ് പ്രോക്സി അതിന്റെ ആന്തരിക പ്രതീക്ഷാ ഹെഡർ നേരിട്ട് പരിശോധിക്കുന്നില്ല. ഇടപെടൽ അല്ലെങ്കിൽ പ്ലെയിൻടെക്സ്റ്റ് ഫോർവേഡിംഗ് പാത വ്യത്യസ്തമാണ്.

പ്രതീക്ഷ നീക്കം ചെയ്യുന്നത് ബോധപൂർവമായ ഒരു അനുയോജ്യതാ തിരഞ്ഞെടുപ്പാകാം, പക്ഷേ അതിന്റെ അർത്ഥം ഒരു മുൻകൂട്ടിയുള്ള നിരസനത്തെക്കുറിച്ച് അറിയുന്നതിന് മുമ്പ് ക്ലയന്റ് വലിയ ബോഡി അയയ്ക്കാൻ തുടങ്ങിയേക്കാം എന്നതാണ്. ആ പെരുമാറ്റത്തെ യഥാർത്ഥ ആവശ്യകതയുമായി താരതമ്യം ചെയ്യുക. പഴയ പ്രോക്സിക്കുള്ള ചരിത്രപരമായ ഒരു പരിഹാരത്തെ എല്ലാ അപ്‌ലോഡിൽ നിന്നും ഹെഡർ നീക്കം ചെയ്യാനുള്ള സാർവത്രിക നിർദ്ദേശമായി വിവരിക്കരുത്.