ทำไมความล้มเหลวของพร็อกซี SockJS จึงอาจปรากฏเฉพาะหลังการสลับไปใช้เส้นทางสำรอง

เมื่อ WebSocket ทำงานบนเครือข่ายหนึ่งแต่ SockJS ล้มเหลวบนอีกเครือข่ายหนึ่ง เครือข่ายที่สองอาจเปิดใช้การสลับไปใช้ XHR สิ่งนี้อาจเปลี่ยนการทำงานของ HTTP ที่ทำคำขอ — และดังนั้นการกำหนดค่าพร็อกซีที่ใช้

ค้นหา URL แรกที่ล้มเหลวและการรับส่งที่มันเลือก SockJS อาจส่งคำขอข้อมูล HTTP ก่อนเลือกการรับส่ง การจับมือ WebSocket และคำขอโพลล์ที่ตามมาเป็นการดำเนินการแยกกัน การกำหนดค่าการจับมือที่ใช้งานได้ไม่ได้พิสูจน์เส้นทางที่ใช้สำหรับแต่ละอย่าง

ในไคลเอนต์ Java ของ Spring RestTemplateXhrTransport ยอมรับ RestTemplate ที่กำหนดค่าไว้ โรงงานคำขอและไคลเอนต์ HTTP ภายใต้มันให้เส้นทางพร็อกซีและการพิสูจน์ตัวตนที่เส้นทางสำรองรองรับ สำหรับ Spring 6 กับ HttpClient 5 กำหนดค่าโรงงานคำขอจริงของ RestTemplate นั้น หากการใช้งานนั้นใช้ส่วนประกอบ Apache HTTP รุ่นของมันต้องตรงกับการผสานรวม

ไคลเอนต์ WebSocket มีการตั้งค่าการเชื่อมต่อที่จัดทำเอกสารไว้เอง คุณสมบัติพร็อกซีของ JVM มีผลกับเส้นทางก็ต่อเมื่อไคลเอนต์เฉพาะของมันอ่านค่าเหล่านั้น เปรียบเทียบสภาพแวดล้อมที่ใช้งานได้และที่ล้มเหลวตามการรับส่ง การใช้งานไคลเอนต์ พร็อกซีที่เลือก และข้อผิดพลาดแรก หากมีเพียง XHR ที่ล้มเหลว ให้ติดตามเส้นทาง การพิสูจน์ตัวตน และการตอบกลับที่คงอยู่ยาวนานของมัน แทนที่จะเปลี่ยนการตั้งค่าของไคลเอนต์ WebSocket ที่ใช้งานได้ซ้ำแล้วซ้ำเล่า