SockJS പ്രോക്സി പരാജയം ഫോൾബാക്കിന് ശേഷം മാത്രം പ്രത്യക്ഷപ്പെടാവുന്നത് എന്തുകൊണ്ട്

ഒരു നെറ്റ്‌വർക്കിൽ WebSocket പ്രവർത്തിക്കുകയും മറ്റൊന്നിൽ SockJS പരാജയപ്പെടുകയും ചെയ്താൽ, രണ്ടാമത്തെ നെറ്റ്‌വർക്ക് XHR ഫോൾബാക്ക് സജീവമാക്കിയിരിക്കാം. അത് അഭ്യർത്ഥനകൾ നടത്തുന്ന HTTP നടപ്പാക്കൽ മാറ്റിയേക്കാം — അതുവഴി ഉപയോഗിക്കുന്ന പ്രോക്സി കോൺഫിഗറേഷനും മാറും.

ആദ്യം പരാജയപ്പെട്ട URL-ഉം അത് തിരഞ്ഞെടുത്ത ട്രാൻസ്പോർട്ടും കണ്ടെത്തുക. SockJS ഒരു ട്രാൻസ്പോർട്ട് തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ഒരു HTTP വിവര അഭ്യർത്ഥന നടത്തിയേക്കാം; WebSocket ഹാൻഡ്ഷേക്കും തുടർന്നുള്ള പോളിംഗ് അഭ്യർത്ഥനകളും വെവ്വേറെ പ്രവർത്തനങ്ങളാണ്. പ്രവർത്തിക്കുന്ന ഹാൻഡ്ഷേക്ക് കോൺഫിഗറേഷൻ അവയിൽ ഓരോന്നിനും ഉപയോഗിക്കുന്ന പാത തെളിയിക്കുന്നില്ല.

Spring-ന്റെ Java ക്ലയന്റിൽ RestTemplateXhrTransport കോൺഫിഗർ ചെയ്ത RestTemplate സ്വീകരിക്കുന്നു. അതിന്റെ അഭ്യർത്ഥന ഫാക്ടറിയും അടിസ്ഥാന HTTP ക്ലയന്റും ഫോൾബാക്ക് പിന്തുണയ്ക്കുന്ന പ്രോക്സി പാതയും പ്രാമാണീകരണവും നൽകുന്നു. HttpClient 5-നൊപ്പം Spring 6-നായി, ആ RestTemplate-ന്റെ യഥാർത്ഥ അഭ്യർത്ഥന ഫാക്ടറി കോൺഫിഗർ ചെയ്യുക. ആ നടപ്പാക്കൽ Apache HTTP ഘടകങ്ങൾ ഉപയോഗിക്കുന്നുവെങ്കിൽ, അതിന്റെ തലമുറ ഇന്റഗ്രേഷനുമായി പൊരുത്തപ്പെടണം.

WebSocket ക്ലയന്റിന് അതിന്റേതായ രേഖപ്പെടുത്തിയ കണക്ഷൻ ക്രമീകരണങ്ങളുണ്ട്. JVM പ്രോക്സി ഗുണങ്ങൾ ഒരു പാതയെ സ്വാധീനിക്കുന്നത് അതിന്റെ കൃത്യമായ ക്ലയന്റ് അവ വായിക്കുമ്പോൾ മാത്രമാണ്. പ്രവർത്തിക്കുന്നതും പരാജയപ്പെടുന്നതുമായ പരിതസ്ഥിതികൾ ട്രാൻസ്പോർട്ട്, ക്ലയന്റ് നടപ്പാക്കൽ, തിരഞ്ഞെടുത്ത പ്രോക്സി, ആദ്യ പിശക് എന്നിവയുടെ അടിസ്ഥാനത്തിൽ താരതമ്യം ചെയ്യുക. XHR മാത്രം പരാജയപ്പെടുന്നുവെങ്കിൽ, പ്രവർത്തിക്കുന്ന WebSocket ക്ലയന്റിന്റെ ക്രമീകരണങ്ങൾ ആവർത്തിച്ച് മാറ്റുന്നതിന് പകരം അതിന്റെ പാതയും പ്രാമാണീകരണവും ദീർഘനേരം നിലനിൽക്കുന്ന പ്രതികരണങ്ങളും പിന്തുടരുക.