SockJS प्रॉक्सी विफलता केवल फ़ॉलबैक के बाद ही क्यों दिख सकती है

जब एक नेटवर्क पर WebSocket काम करता है पर दूसरे पर SockJS विफल होता है, तो दूसरे नेटवर्क ने XHR फ़ॉलबैक शुरू किया हो सकता है। यह उन अनुरोधों को करने वाले HTTP कार्यान्वयन को बदल सकता है — और इसलिए उपयोग हो रहे प्रॉक्सी कॉन्फ़िगरेशन को भी।

पहला विफल URL और उसके द्वारा चुना गया ट्रांसपोर्ट खोजें। SockJS ट्रांसपोर्ट चुनने से पहले एक HTTP सूचना अनुरोध कर सकता है; WebSocket हैंडशेक और उसके बाद के पोलिंग अनुरोध अलग-अलग क्रियाएँ हैं। काम करने वाला हैंडशेक कॉन्फ़िगरेशन उनमें से प्रत्येक के लिए उपयोग होने वाला मार्ग सिद्ध नहीं करता।

Spring के Java क्लाइंट में RestTemplateXhrTransport कॉन्फ़िगर किया गया RestTemplate स्वीकार करता है। इसका अनुरोध फ़ैक्टरी और अंतर्निहित HTTP क्लाइंट फ़ॉलबैक द्वारा समर्थित प्रॉक्सी मार्ग और प्रमाणीकरण प्रदान करते हैं। HttpClient 5 के साथ Spring 6 के लिए, उस RestTemplate की वास्तविक अनुरोध फ़ैक्टरी कॉन्फ़िगर करें। यदि वह कार्यान्वयन Apache HTTP घटकों का उपयोग करता है, तो उसकी पीढ़ी को एकीकरण से मेल खाना चाहिए।

WebSocket क्लाइंट की अपनी प्रलेखित कनेक्शन सेटिंग हैं। JVM प्रॉक्सी गुण किसी मार्ग को केवल तभी प्रभावित करते हैं जब उसका ठोस क्लाइंट उन्हें पढ़ता है। काम करने वाले और विफल वातावरण की तुलना ट्रांसपोर्ट, क्लाइंट कार्यान्वयन, चुने गए प्रॉक्सी और पहली त्रुटि के आधार पर करें। यदि केवल XHR विफल होता है, तो काम करने वाले WebSocket क्लाइंट की सेटिंग बार-बार बदलने के बजाय उसके मार्ग, प्रमाणीकरण और लंबे समय तक बने रहने वाले उत्तरों का अनुसरण करें।