Kvifor ein SockJS-proxyfeil først kan vise seg etter fallback

Når WebSocket fungerer på eitt nettverk, men SockJS feilar på eit anna, kan det andre nettverket ha utløyst XHR-fallbacken. Det kan endre HTTP-implementasjonen som utfører førespurnadene — og dermed proxykonfigurasjonen som blir brukt.

Finn den første mislukka URL-en og transporten han valde. SockJS kan senda ein HTTP-informasjonsførespurnad før det vel ein transport; WebSocket-handtrykket og påfølgjande pollingførespurnader er separate operasjonar. Ein fungerande handtrykkskonfigurasjon beviser ikkje banen som blir brukt for kvar av dei.

I Java-klienten til Spring godtek RestTemplateXhrTransport ein konfigurert RestTemplate. Førespurnadsfabrikken og den underliggjande HTTP-klienten leverer proxybanen og autentiseringa som fallbacken støttar. For Spring 6 med HttpClient 5, konfigurer den faktiske førespurnadsfabrikken til den RestTemplate-en. Viss den implementasjonen brukar Apache HTTP-komponentar, må generasjonen hans passe med integrasjonen.

WebSocket-klienten har eigne dokumenterte tilkoplingsinnstillingar. JVM-proxyeggenskapar påverkar ein bane berre viss den konkrete klienten les dei. Samanlikn miljøet som fungerer, og miljøet som feilar, etter transport, klientimplementasjon, vald proxy og første feil. Viss berre XHR feilar, følg banen, autentiseringa og dei langvarige responsane i staden for å endre innstillingane til den fungerande WebSocket-klienten om og om att.