Zašto se kvar SockJS proxyja može pojaviti tek nakon prijelaza na rezervni put
WebSocket put i XHR rezervni put mogu koristiti različite HTTP klijente. Utvrdite transport koji ne uspijeva prije nego promijenite njegove postavke proxyja.
Kada WebSocket radi na jednoj mreži, a SockJS zataji na drugoj, druga je mreža možda pokrenula XHR rezervni put. To može promijeniti HTTP implementaciju koja izvršava zahtjeve — a time i konfiguraciju proxyja koja se koristi.
Pronađite prvi neuspjeli URL i njegov odabrani transport. SockJS može poslati HTTP informacijski zahtjev prije odabira transporta; WebSocket rukovanje i sljedeći polling zahtjevi odvojene su operacije. Ispravna konfiguracija rukovanja ne dokazuje put koji se koristi za svaku od njih.
U Springovu Java klijentu RestTemplateXhrTransport prihvaća konfigurirani RestTemplate. Njegova tvornica zahtjeva i temeljni HTTP klijent pružaju put proxyja i autentifikaciju koje rezervni put podržava. Za Spring 6 s HttpClient 5 konfigurirajte stvarnu tvornicu zahtjeva tog RestTemplatea. Ako ta implementacija koristi Apache HTTP komponente, njezina generacija mora odgovarati integraciji.
WebSocket klijent ima vlastite dokumentirane postavke veze. Svojstva JVM proxyja utječu na put samo ako ih njegov konkretni klijent čita. Usporedite radno i neuspjelo okruženje prema transportu, implementaciji klijenta, odabranom proxyju i prvoj pogrešci. Ako zataji samo XHR, slijedite njegov put, autentifikaciju i dugotrajne odgovore umjesto da iznova mijenjate postavke radnog WebSocket klijenta.