ولې د SockJS پراکسي ناکامي يوازې د بېرته راستنېدو وروسته ښکاره کېدای شي

کله چې WebSocket په یوه شبکه کې کار وکړي خو SockJS په بله کې ناکام شي، کېدای شي دویمې شبکې XHR بېرته راستنېدنه پیل کړې وي. دا کولای شي هغه HTTP تطبیق بدل کړي چې غوښتنې کوي — او له همدې امله کارول شوې پراکسي ترتیبات هم.

لومړنی ناکام URL او د هغې ټاکل شوی ټرانسپورټ ومومئ. SockJS کولای شي د ټرانسپورټ له ټاکلو دمخه د HTTP معلوماتي غوښتنه وکړي؛ د WebSocket لاس ورکول او وروسته پولینګ غوښتنې جلا عملیات دي. کاري لاس ورکولو ترتیبات د دوی هر یو لپاره کارول شوې لار ثابتوي نه.

د Spring په Java کلاینټ کې RestTemplateXhrTransport یو ترتیب شوی RestTemplate مني. د هغې غوښتنې فابریکه او لاندې HTTP کلاینټ هغه پراکسي لار او تصدیق وړاندې کوي چې بېرته راستنېدنه یې ملاتړ کوي. د Spring 6 لپاره د HttpClient 5 سره، د هغې RestTemplate ریښتینې غوښتنې فابریکه ترتیب کړئ. که هغه تطبیق د Apache HTTP برخې وکاروي، د هغې نسل باید له ادغام سره سمون ولري.

د WebSocket کلاینټ خپل مستند شوي نښلونکي تنظیمات لري. د JVM پراکسي ځانګړنې یوازې هغه وخت پر لار اغېزه کوي چې د هغې مشخص کلاینټ یې ولولي. کاري او ناکام چاپېریالونه د ټرانسپورټ، کلاینټ تطبیق، ټاکل شوې پراکسي او لومړنۍ تېروتنې له مخې پرتله کړئ. که یوازې XHR ناکام شي، د کاري WebSocket کلاینټ تنظیماتو په تکراري بدلولو پرځای د هغې لار، تصدیق او اوږد مهاله ځوابونه تعقیب کړئ.