Pse një dështim i proxy-t SockJS mund të shfaqet vetëm pas kalimit në rrugën rezervë
Rruga WebSocket dhe rruga rezervë XHR mund të përdorin klientë HTTP të ndryshëm. Identifikoni transportin që dështon përpara se të ndryshoni cilësimet e tij të proxy-t.
Kur WebSocket funksionon në një rrjet, por SockJS dështon në një tjetër, rrjeti i dytë mund të ketë aktivizuar rrugën rezervë XHR. Kjo mund të ndryshojë implementimin HTTP që bën kërkesat — dhe për rrjedhojë konfigurimin e proxy-t që përdoret.
Gjeni URL-në e parë që dështoi dhe transportin e zgjedhur prej saj. SockJS mund të bëjë një kërkesë informacioni HTTP përpara se të zgjedhë një transport; shtrëngimi i duarve i WebSocket dhe kërkesat e mëvonshme të sondazhit janë operacione të veçanta. Një konfigurim funksional i shtrëngimit të duarve nuk vërteton rrugën e përdorur për secilin prej tyre.
Në klientin Java të Spring, RestTemplateXhrTransport pranon një RestTemplate të konfiguruar. Fabrika e kërkesave dhe klienti HTTP në themel ofrojnë rrugën e proxy-t dhe vërtetimin e mbështetur nga rruga rezervë. Për Spring 6 me HttpClient 5, konfiguroni fabrikën aktuale të kërkesave të atij RestTemplate. Nëse ai implementim përdor komponentë Apache HTTP, gjenerata e tij duhet të përputhet me integrimin.
Klienti WebSocket ka cilësimet e tij të dokumentuara të lidhjes. Vetitë e proxy-t të JVM ndikojnë në një rrugë vetëm nëse klienti i tij konkret i lexon ato. Krahasoni mjediset që funksionojnë dhe ato që dështojnë sipas transportit, implementimit të klientit, proxy-t të zgjedhur dhe gabimit të parë. Nëse dështon vetëm XHR, ndiqni rrugën, vërtetimin dhe përgjigjet e tij afatgjata në vend që të ndryshoni vazhdimisht cilësimet e klientit WebSocket që funksionon.