Mengapa kegagalan proksi SockJS boleh muncul hanya selepas fallback

Apabila WebSocket berfungsi pada satu rangkaian tetapi SockJS gagal pada rangkaian lain, rangkaian kedua mungkin telah mencetuskan fallback XHR. Itu boleh menukar pelaksanaan HTTP yang membuat permintaan — dan oleh itu konfigurasi proksi yang digunakan.

Cari URL pertama yang gagal dan pengangkutan yang dipilihnya. SockJS boleh membuat permintaan maklumat HTTP sebelum memilih pengangkutan; jabat tangan WebSocket dan permintaan tinjauan seterusnya ialah operasi berasingan. Konfigurasi jabat tangan yang berfungsi tidak membuktikan laluan yang digunakan untuk setiap satunya.

Dalam klien Java Spring, RestTemplateXhrTransport menerima RestTemplate yang dikonfigurasikan. Kilang permintaan dan klien HTTP asasnya menyediakan laluan proksi dan pengesahan yang disokong oleh fallback. Untuk Spring 6 dengan HttpClient 5, konfigurasikan kilang permintaan sebenar RestTemplate itu. Jika pelaksanaan itu menggunakan komponen Apache HTTP, generasinya mesti sepadan dengan integrasi.

Klien WebSocket mempunyai tetapan sambungannya sendiri yang didokumenkan. Sifat proksi JVM mempengaruhi laluan hanya jika klien konkritnya membacanya. Bandingkan persekitaran yang berfungsi dan yang gagal mengikut pengangkutan, pelaksanaan klien, proksi yang dipilih dan ralat pertama. Jika hanya XHR gagal, ikut laluan, pengesahan dan responsnya yang tahan lama dan bukan menukar tetapan klien WebSocket yang berfungsi berulang kali.