Mengapa kegagalan proxy SockJS bisa muncul hanya setelah fallback

Saat WebSocket berfungsi di satu jaringan tetapi SockJS gagal di jaringan lain, jaringan kedua mungkin telah memicu fallback XHR. Itu dapat mengubah implementasi HTTP yang membuat permintaan — dan karena itu konfigurasi proxy yang dipakai.

Temukan URL pertama yang gagal dan transport yang dipilihnya. SockJS dapat membuat permintaan informasi HTTP sebelum memilih transport; jabat tangan WebSocket dan permintaan polling berikutnya adalah operasi terpisah. Konfigurasi jabat tangan yang berfungsi tidak membuktikan rute yang dipakai untuk masing-masingnya.

Di klien Java Spring, RestTemplateXhrTransport menerima RestTemplate yang dikonfigurasi. Pabrik permintaan dan klien HTTP yang mendasarinya menyediakan rute proxy dan autentikasi yang didukung fallback. Untuk Spring 6 dengan HttpClient 5, konfigurasikan pabrik permintaan sebenarnya dari RestTemplate tersebut. Jika implementasi itu memakai komponen Apache HTTP, generasinya harus cocok dengan integrasinya.

Klien WebSocket memiliki setelan koneksi terdokumentasi sendiri. Properti proxy JVM memengaruhi suatu rute hanya jika klien konkretnya membacanya. Bandingkan lingkungan yang berfungsi dan yang gagal berdasarkan transport, implementasi klien, proxy yang dipilih, dan kesalahan pertama. Jika hanya XHR yang gagal, ikuti rute, autentikasi, dan responsnya yang berlangsung lama alih-alih berulang kali mengubah setelan klien WebSocket yang berfungsi.