De ce o defecțiune a proxy-ului SockJS poate apărea abia după fallback
Calea WebSocket și calea de rezervă XHR pot folosi clienți HTTP diferiți. Identificați transportul care eșuează înainte de a-i modifica setările de proxy.
Când WebSocket funcționează într-o rețea, dar SockJS eșuează în alta, cea de-a doua rețea poate fi declanșat calea de rezervă XHR. Aceasta poate schimba implementarea HTTP care face cererile — și, prin urmare, configurația de proxy folosită.
Găsiți primul URL eșuat și transportul ales de acesta. SockJS poate face o cerere HTTP informativă înainte de a alege un transport; handshake-ul WebSocket și cererile de sondare ulterioare sunt operații separate. O configurație de handshake funcțională nu dovedește calea folosită pentru fiecare dintre ele.
În clientul Java al Spring, RestTemplateXhrTransport acceptă un RestTemplate configurat. Fabrica sa de cereri și clientul HTTP subiacent furnizează ruta de proxy și autentificarea acceptate de calea de rezervă. Pentru Spring 6 cu HttpClient 5, configurați fabrica reală de cereri a acelui RestTemplate. Dacă acea implementare folosește componente Apache HTTP, generația ei trebuie să corespundă integrării.
Clientul WebSocket are propriile setări de conexiune documentate. Proprietățile de proxy ale JVM afectează o cale numai dacă clientul ei concret le citește. Comparați mediile funcțional și eșuat după transport, implementarea clientului, proxy-ul ales și prima eroare. Dacă eșuează doar XHR, urmați ruta, autentificarea și răspunsurile de lungă durată ale acestuia, în loc să modificați repetat setările clientului WebSocket funcțional.