מדוע כשל פרוקסי של SockJS עשוי להופיע רק לאחר המעבר למסלול החלופי
מסלול ה-WebSocket והמסלול החלופי ב-XHR עשויים להשתמש בלקוחות HTTP שונים. זהו את התעבורה שנכשלת לפני שתשנו את הגדרות הפרוקסי שלה.
כאשר WebSocket עובד ברשת אחת אך SockJS נכשל ברשת אחרת, ייתכן שהרשת השנייה הפעילה את המסלול החלופי ב-XHR. הדבר עשוי לשנות את מימוש ה-HTTP שמבצע את הבקשות — ולכן גם את תצורת הפרוקסי שמשמשת.
אתרו את כתובת ה-URL הראשונה שנכשלה ואת התעבורה שנבחרה עבורה. SockJS עשוי לשלוח בקשת מידע ב-HTTP לפני בחירת תעבורה; לחיצת היד של WebSocket ובקשות הסקירה שלאחריה הן פעולות נפרדות. תצורת לחיצת יד שעובדת אינה מוכיחה את המסלול שמשמש לכל אחת מהן.
בלקוח ה-Java של Spring, RestTemplateXhrTransport מקבל RestTemplate מוגדר. מפעל הבקשות שלו ולקוח ה-HTTP שמתחתיו מספקים את מסלול הפרוקסי והאימות שהמסלול החלופי תומך בהם. עבור Spring 6 עם HttpClient 5, הגדירו את מפעל הבקשות בפועל של אותו RestTemplate. אם המימוש הזה משתמש ברכיבי Apache HTTP, הדור שלו חייב להתאים לאינטגרציה.
ללקוח ה-WebSocket יש הגדרות חיבור מתועדות משלו. מאפייני פרוקסי של JVM משפיעים על מסלול רק אם הלקוח הקונקרטי שלו קורא אותם. השוו בין הסביבה שעובדת לזו שנכשלת לפי תעבורה, מימוש הלקוח, הפרוקסי שנבחר והשגיאה הראשונה. אם רק XHR נכשל, עקבו אחר המסלול, האימות והתגובות ארוכות הטווח שלו במקום לשנות שוב ושוב את הגדרות לקוח ה-WebSocket שעובד.