Hvorfor en SockJS-proxyfejl kan vise sig først efter fallback

Når WebSocket virker på ét netværk, men SockJS fejler på et andet, kan det andet netværk have udløst XHR-fallback. Det kan ændre den HTTP-implementering, der udfører anmodningerne — og dermed den proxykonfiguration, der bruges.

Find den første mislykkede URL og den transport, den valgte. SockJS kan sende en HTTP-informationsanmodning, før den vælger en transport; WebSocket-håndtrykket og efterfølgende pollinganmodninger er separate handlinger. En fungerende håndtrykskonfiguration beviser ikke den rute, der bruges for hver af dem.

I Springs Java-klient accepterer RestTemplateXhrTransport en konfigureret RestTemplate. Dens anmodningsfabrik og underliggende HTTP-klient leverer den proxy-rute og godkendelse, som fallbacken understøtter. For Spring 6 med HttpClient 5 skal du konfigurere den pågældende RestTemplates faktiske anmodningsfabrik. Hvis den implementering bruger Apache HTTP-komponenter, skal dens generation passe til integrationen.

WebSocket-klienten har sine egne dokumenterede forbindelsesindstillinger. JVM-proxyegenskaber påvirker kun en rute, hvis dens konkrete klient læser dem. Sammenlign de fungerende og fejlende miljøer efter transport, klientimplementering, valgt proxy og første fejl. Hvis kun XHR fejler, følg dens rute, godkendelse og langvarige svar i stedet for gentagne gange at ændre indstillingerne for den fungerende WebSocket-klient.