Bakit ang pagkabigo ng SockJS proxy ay maaaring lumitaw lamang pagkatapos ng fallback
Ang WebSocket path at XHR fallback ay maaaring gumamit ng magkaibang HTTP client. Tukuyin ang transport na nabigo bago baguhin ang mga setting ng proxy nito.
Kapag gumagana ang WebSocket sa isang network ngunit nabigo ang SockJS sa iba, maaaring na-trigger ng pangalawang network ang XHR fallback. Maaaring baguhin nito ang implementasyon ng HTTP na gumagawa ng mga kahilingan — at dahil dito ang ginagamit na configuration ng proxy.
Hanapin ang unang nabigong URL at ang transport na pinili nito. Maaaring magpadala ang SockJS ng kahilingan para sa impormasyong HTTP bago pumili ng transport; ang WebSocket handshake at ang mga sumunod na polling request ay magkaibang operasyon. Hindi pinapatunayan ng gumaganang handshake configuration ang rutang ginagamit para sa bawat isa sa kanila.
Sa Java client ng Spring, tumatanggap ang RestTemplateXhrTransport ng naka-configure na RestTemplate. Ang request factory nito at ang pinagbabatayang HTTP client ay nagbibigay ng rutang proxy at authentication na sinusuportahan ng fallback. Para sa Spring 6 na may HttpClient 5, i-configure ang aktwal na request factory ng RestTemplate na iyon. Kung gumagamit ang implementasyong iyon ng mga bahagi ng Apache HTTP, dapat tumugma ang henerasyon nito sa integrasyon.
May sariling dokumentadong mga setting ng koneksyon ang WebSocket client. Ang mga property ng JVM proxy ay nakakaapekto sa isang ruta lamang kung binabasa ito ng konkretong client nito. Ihambing ang gumagana at nabigong kapaligiran ayon sa transport, implementasyon ng client, piniling proxy at unang error. Kung XHR lamang ang nabigo, sundan ang ruta, authentication at pangmatagalang tugon nito sa halip na paulit-ulit na baguhin ang mga setting ng gumaganang WebSocket client.