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 کلائنٹ کی ترتیبات بار بار بدلنے کے بجائے اس کے راستے، توثیق اور طویل مدت تک رہنے والے جوابات کی پیروی کریں۔