Zakaj se napaka proxy SockJS lahko pojavi šele po prehodu na rezervno pot
Pot WebSocket in rezervna pot XHR lahko uporabljata različne odjemalce HTTP. Preden spremenite nastavitve proxy, ugotovite, kateri prenos ne uspe.
Ko WebSocket deluje v enem omrežju, SockJS pa v drugem ne uspe, je drugo omrežje morda sprožilo rezervno pot XHR. To lahko spremeni izvedbo HTTP, ki izvaja zahteve — in zato tudi uporabljeno konfiguracijo proxy.
Poiščite prvi neuspešni URL in njegov izbrani prenos. SockJS lahko pred izbiro prenosa izvede informacijsko zahtevo HTTP; rokovanje WebSocket in nadaljnje zahteve za anketiranje so ločene operacije. Delujoča konfiguracija rokovanja ne dokazuje poti, uporabljene za vsako od njih.
V odjemalcu Java Springa RestTemplateXhrTransport sprejme konfiguriran RestTemplate. Njegova tovarna zahtev in osnovni odjemalec HTTP zagotavljata pot proxyja in preverjanje pristnosti, ki ju podpira rezervna pot. Za Spring 6 s HttpClient 5 konfigurirajte dejansko tovarno zahtev tega RestTemplate. Če ta izvedba uporablja komponente Apache HTTP, se mora njena generacija ujemati z integracijo.
Odjemalec WebSocket ima lastne dokumentirane nastavitve povezave. Lastnosti proxyja JVM vplivajo na pot le, če jih njegov konkretni odjemalec prebere. Primerjajte delujoče in neuspešno okolje po prenosu, izvedbi odjemalca, izbranem proxyju in prvi napaki. Če ne uspe le XHR, sledite njegovi poti, preverjanju pristnosti in dolgotrajnim odgovorom, namesto da znova in znova spreminjate nastavitve delujočega odjemalca WebSocket.