Hvorfor en SockJS-proxyfeil først kan vises etter fallback

Når WebSocket fungerer på ett nettverk, men SockJS feiler på et annet, kan det andre nettverket ha utløst XHR-fallbacken. Det kan endre HTTP-implementasjonen som utfører forespørslene — og dermed proxykonfigurasjonen som brukes.

Finn den første mislykkede URL-en og transporten den valgte. SockJS kan sende en HTTP-informasjonsforespørsel før den velger en transport; WebSocket-håndtrykket og påfølgende pollingforespørsler er separate operasjoner. En fungerende håndtrykkskonfigurasjon beviser ikke banen som brukes for hver av dem.

I Springs Java-klient godtar RestTemplateXhrTransport en konfigurert RestTemplate. Forespørselsfabrikken og den underliggende HTTP-klienten leverer proxybanen og autentiseringen som fallbacken støtter. For Spring 6 med HttpClient 5, konfigurer den faktiske forespørselsfabrikken til den RestTemplate-en. Hvis den implementasjonen bruker Apache HTTP-komponenter, må generasjonen samsvare med integrasjonen.

WebSocket-klienten har egne dokumenterte tilkoblingsinnstillinger. JVM-proxyegenskaper påvirker en bane bare hvis den konkrete klienten leser dem. Sammenlign miljøet som fungerer, og miljøet som feiler, etter transport, klientimplementasjon, valgt proxy og første feil. Hvis bare XHR feiler, følg banen, autentiseringen og de langvarige responsene i stedet for å endre innstillingene til den fungerende WebSocket-klienten gjentatte ganger.