Firwat e SockJS-Proxyfehler eréischt nom Fallback kann optrieden
De WebSocket-Wee an en XHR-Fallback kënnen ënnerschiddlech HTTP-Clienten benotzen. Identifizéiert den Transport, dee feelt, ier Dir seng Proxy-Astellungen ännert.
Wann WebSocket an engem Netzwierk funktionéiert, awer SockJS an engem aneren feelt, huet dat zweet Netzwierk vläicht den XHR-Fallback ausgeléist. Dat kann d'HTTP-Implementatioun änneren, déi d'Ufroen ausféiert — an domat d'Proxy-Konfiguratioun, déi benotzt gëtt.
Fannt déi éischt feelgeschloen URL an den Transport, deen se gewielt huet. SockJS kann eng HTTP-Informatiounsofro maachen, ier en en Transport wielt; den WebSocket-Handshake an déi duerno Polling-Ufroe sinn getrennt Operatiounen. Eng funktionéierend Handshake-Konfiguratioun beweist net de Wee, dee fir jiddweree vun hinnen benotzt gëtt.
Am Java-Client vu Spring akzeptéiert RestTemplateXhrTransport eng konfiguréiert RestTemplate. Seng Ufro-Fabrik an den ënnerierdeschen HTTP-Client liwweren de Proxy-Wee an d'Authentifikatioun, déi vum Fallback ënnerstëtzt ginn. Fir Spring 6 mat HttpClient 5, konfiguréiert déi tatsächlech Ufro-Fabrik vun där RestTemplate. Wann déi Implementatioun Apache-HTTP-Komponente benotzt, muss hir Generatioun mat der Integratioun passen.
Den WebSocket-Client huet seng eege dokumentéiert Verbindungsastellungen. JVM-Proxy-Eegeschaften beaflossen e Wee nëmmen, wann säi konkreten Client se liest. Vergläicht déi funktionéierend an déi feelend Ëmwelt no Transport, Client-Implementatioun, gewielte Proxy an éischte Fehler. Wann nëmmen XHR feelt, befollegt säi Wee, seng Authentifikatioun a seng laang gehalen Äntwerten, amplaz d'Astellunge vum funktionéierende WebSocket-Client ëmmer erëm z'änneren.