ফলব্যাকের পরেই 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 ক্লায়েন্টের সেটিংস বারবার বদলানোর বদলে তার পথ, প্রমাণীকরণ ও দীর্ঘস্থায়ী প্রতিক্রিয়া অনুসরণ করুন।