പ്രോക്സി പ്രാമാണീകരണത്തിന്റെ വീണ്ടും ശ്രമങ്ങളും ആവർത്തിക്കാൻ കഴിയാത്ത അപ്‌ലോഡ് ബോഡികളും

ഒരു GET പ്രോക്സി വഴി പ്രാമാണീകരിക്കാം, എന്നാൽ POST അല്ലെങ്കിൽ PUT ആവർത്തിക്കാൻ കഴിയാത്ത ബോഡി അല്ലെങ്കിൽ റിവൈൻഡ് പിശകിനാൽ പരാജയപ്പെടുന്നു. അക്കൗണ്ട് ശരിയായിരിക്കാം: ക്ലയന്റ് അപ്‌ലോഡ് ഉപയോഗിച്ചതിന് ശേഷവും പ്രാമാണീകരണ കൈമാറ്റത്തിന് മറ്റൊരു അഭ്യർത്ഥന ആവശ്യമായി വന്നേക്കാം.

libcurl മൾട്ടി-പാസ് പ്രാമാണീകരണം ഉൾപ്പെടെയുള്ള ഉപയോഗങ്ങൾക്കായി തിരയൽ കോൾബാക്കുകൾ രേഖപ്പെടുത്തുന്നു. Jersey കണക്ടറിന്റെ സ്വഭാവത്തിന് വിധേയമായി ബഫർ ചെയ്തതും വിഭജിച്ചതുമായ എന്റിറ്റി പ്രോസസ്സിംഗ് മോഡുകൾ വാഗ്ദാനം ചെയ്യുന്നു. ഒരു Jersey 2 Apache കണക്ടർ ഉദാഹരണം ബഫർ ചെയ്ത ക്രമീകരണം കാണിക്കുന്നു. ഇവയൊന്നും പരിധിയില്ലാത്ത ഇൻ-മെമ്മറി അപ്‌ലോഡുകളെ ഉചിതമാക്കുന്നില്ല.

പരാജയപ്പെടുന്ന രീതിയും ബോഡി ഉറവിടവും പുനർനിർമ്മിക്കുക. ഒരു തയ്യാറെടുപ്പ് GET-ന് ആവർത്തിക്കാൻ അപ്‌ലോഡ് ഇല്ല, കൂടാതെ പിന്നീടുള്ള അപ്‌ലോഡ് അതിന്റെ കണക്ഷനോ പ്രാമാണീകരണ അവസ്ഥയോ പങ്കിടുന്നുവെന്ന് അത് തെളിയിക്കുന്നില്ല. പുതിയ ലക്ഷ്യസ്ഥാനം, ക്ലയന്റ് ഒബ്ജക്റ്റ് അല്ലെങ്കിൽ കണക്ഷൻ നയം അത് മാറ്റാം. ഫയൽ അടിസ്ഥാനമാക്കിയ ബോഡിയും ലൈവ് സ്ട്രീമും അവയുടെ സാമ്പിൾ ടെക്സ്റ്റ് ഒന്നുതന്നെയാണെങ്കിലും വ്യത്യസ്തമാണ്.

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

അറിയപ്പെടുന്ന അനുയോജ്യമായ പ്രോക്സിയിലേക്കുള്ള മുൻകൂർ പ്രാമാണീകരണം ഒരു പ്രാരംഭ വെല്ലുവിളി ഒഴിവാക്കാം. എന്നാൽ മറ്റൊരു ശ്രമം ആവശ്യമായി വന്നേക്കാവുന്ന ഓരോ പിന്നീടുള്ള പ്രാമാണീകരണ റൗണ്ട്, റീഡയറക്ട് അല്ലെങ്കിൽ അടച്ച കണക്ഷൻ അതിന് ഒഴിവാക്കാനാവില്ല.

പ്രോക്സിയുടെ പ്രതികരണം, ബോഡി ഉപഭോഗ പോയിന്റ്, ആവർത്തന പിശക് എന്നിവ ഒരുമിച്ച് സൂക്ഷിക്കുക. തുടർന്ന് പ്രോട്ടോക്കോൾ ആവർത്തനത്തെ അനിശ്ചിതമായ അപ്ലിക്കേഷൻ ഫലത്തിൽ നിന്ന് വേർതിരിക്കുക: പ്രതികരണം നഷ്ടപ്പെടുന്നതിന് മുമ്പ് സമർപ്പണം പ്രോസസ്സ് ചെയ്തിരിക്കാം. വീണ്ടും അയയ്ക്കുന്നതിന് മുമ്പ് ലക്ഷ്യസ്ഥാനത്തിന്റെ idempotency നിയമങ്ങൾ പാലിക്കുക.