Zašto se kvar SockJS proksija može pojaviti tek nakon rezervnog puta
WebSocket put i XHR rezervni put mogu koristiti različite HTTP klijente. Utvrdite koji transport ne uspeva pre nego što promenite njegova podešavanja proksija.
Kada WebSocket radi na jednoj mreži, a SockJS ne uspeva na drugoj, druga mreža je možda pokrenula XHR rezervni put. To može promeniti HTTP implementaciju koja izvršava zahteve — a time i konfiguraciju proksija koja se koristi.
Pronađite prvi neuspešni URL i njegov izabrani transport. SockJS može poslati HTTP informacioni zahtev pre izbora transporta; WebSocket rukovanje i naredni polling zahtevi su odvojene operacije. Ispravna konfiguracija rukovanja ne dokazuje put koji se koristi za svaku od njih.
U Springovom Java klijentu RestTemplateXhrTransport prihvata konfigurisani RestTemplate. Njegova fabrika zahteva i osnovni HTTP klijent obezbeđuju put proksija i autentifikaciju koje rezervni put podržava. Za Spring 6 sa HttpClient 5 konfigurišite stvarnu fabriku zahteva tog RestTemplatea. Ako ta implementacija koristi Apache HTTP komponente, njena generacija mora odgovarati integraciji.
WebSocket klijent ima sopstvena dokumentovana podešavanja veze. Svojstva JVM proksija utiču na put samo ako ih njegov konkretni klijent čita. Uporedite radno i neuspešno okruženje po transportu, implementaciji klijenta, izabranom proksiju i prvoj grešci. Ako ne uspeva samo XHR, pratite njegov put, autentifikaciju i dugotrajne odgovore umesto da iznova menjate podešavanja radnog WebSocket klijenta.