Waarom een SockJS-proxyfout pas na de fallback kan optreden
Het WebSocket-pad en een XHR-fallback kunnen verschillende HTTP-clients gebruiken. Identificeer het mislukkende transport voordat je de proxyinstellingen ervan wijzigt.
Wanneer WebSocket op het ene netwerk werkt maar SockJS op een ander mislukt, heeft het tweede netwerk mogelijk de XHR-fallback geactiveerd. Dat kan de HTTP-implementatie veranderen die de verzoeken doet — en daarmee de gebruikte proxyconfiguratie.
Zoek de eerste mislukte URL en het gekozen transport. SockJS kan een HTTP-informatieverzoek doen voordat het een transport kiest; de WebSocket-handshake en volgende pollingverzoeken zijn afzonderlijke bewerkingen. Een werkende handshakeconfiguratie bewijst niet welk pad voor elk ervan wordt gebruikt.
In de Java-client van Spring accepteert RestTemplateXhrTransport een geconfigureerde RestTemplate. De requestfactory en onderliggende HTTP-client leveren de proxypad en authenticatie die de fallback ondersteunt. Voor Spring 6 met HttpClient 5 configureer je de werkelijke requestfactory van die RestTemplate. Als die implementatie Apache HTTP-componenten gebruikt, moet de generatie ervan bij de integratie passen.
De WebSocket-client heeft zijn eigen gedocumenteerde verbindingsinstellingen. JVM-proxyeigenschappen beïnvloeden een pad alleen als de concrete client ze leest. Vergelijk de werkende en mislukkende omgeving op transport, clientimplementatie, gekozen proxy en eerste fout. Als alleen XHR mislukt, volg dan het pad, de authenticatie en de langdurige antwoorden ervan in plaats van herhaaldelijk de instellingen van de werkende WebSocket-client te wijzigen.