SockJS ಪ್ರಾಕ್ಸಿ ವೈಫಲ್ಯವು ಫಾಲ್‌ಬ್ಯಾಕ್ ನಂತರ ಮಾತ್ರ ಏಕೆ ಕಾಣಿಸಬಹುದು
WebSocket ಮಾರ್ಗ ಮತ್ತು XHR ಫಾಲ್‌ಬ್ಯಾಕ್ ಬೇರೆ ಬೇರೆ HTTP ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಬಳಸಬಹುದು. ಅದರ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಿಸುವ ಮೊದಲು ವಿಫಲವಾಗುವ ಸಾರಿಗೆಯನ್ನು ಗುರುತಿಸಿ.
ಒಂದು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ WebSocket ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದರಲ್ಲಿ SockJS ವಿಫಲವಾದರೆ, ಎರಡನೇ ನೆಟ್‌ವರ್ಕ್ XHR ಫಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿರಬಹುದು. ಇದು ವಿನಂತಿಗಳನ್ನು ಮಾಡುವ HTTP ಅನುಷ್ಠಾನವನ್ನು ಬದಲಿಸಬಹುದು — ಮತ್ತು ಆದ್ದರಿಂದ ಬಳಸುವ ಪ್ರಾಕ್ಸಿ ಸಂರಚನೆಯನ್ನೂ ಬದಲಿಸಬಹುದು.
ಮೊದಲ ವಿಫಲ URL ಮತ್ತು ಅದು ಆಯ್ಕೆ ಮಾಡಿದ ಸಾರಿಗೆಯನ್ನು ಹುಡುಕಿ. SockJS ಸಾರಿಗೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು HTTP ಮಾಹಿತಿ ವಿನಂತಿಯನ್ನು ಮಾಡಬಹುದು; WebSocket ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮತ್ತು ನಂತರದ ಪೋಲಿಂಗ್ ವಿನಂತಿಗಳು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯಾಚರಣೆಗಳು. ಕೆಲಸ ಮಾಡುವ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಂರಚನೆಯು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬಳಸುವ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
Spring ನ Java ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ RestTemplateXhrTransport ಸಂರಚಿತ RestTemplate ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಅದರ ವಿನಂತಿ ಕಾರ್ಖಾನೆ ಮತ್ತು ಆಧಾರವಾಗಿರುವ HTTP ಕ್ಲೈಂಟ್ ಫಾಲ್‌ಬ್ಯಾಕ್ ಬೆಂಬಲಿಸುವ ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ಒದಗಿಸುತ್ತವೆ. HttpClient 5 ಜೊತೆಗೆ Spring 6 ಗಾಗಿ, ಆ RestTemplate ನ ನಿಜವಾದ ವಿನಂತಿ ಕಾರ್ಖಾನೆಯನ್ನು ಸಂರಚಿಸಿ. ಆ ಅನುಷ್ಠಾನವು Apache HTTP ಘಟಕಗಳನ್ನು ಬಳಸಿದರೆ, ಅದರ ಪೀಳಿಗೆಯು ಏಕೀಕರಣಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು.
WebSocket ಕ್ಲೈಂಟ್‌ಗೆ ತನ್ನದೇ ದಾಖಲಿತ ಸಂಪರ್ಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ. JVM ಪ್ರಾಕ್ಸಿ ಗುಣಲಕ್ಷಣಗಳು ಮಾರ್ಗವನ್ನು ಪ್ರಭಾವಿಸುವುದು ಅದರ ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನು ಓದಿದಾಗ ಮಾತ್ರ. ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ವಿಫಲವಾಗುವ ಪರಿಸರಗಳನ್ನು ಸಾರಿಗೆ, ಕ್ಲೈಂಟ್ ಅನುಷ್ಠಾನ, ಆಯ್ದ ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಮೊದಲ ದೋಷದ ಮೂಲಕ ಹೋಲಿಸಿ. ಕೇವಲ XHR ವಿಫಲವಾದರೆ, ಕೆಲಸ ಮಾಡುವ WebSocket ಕ್ಲೈಂಟ್‌ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪದೇ ಪದೇ ಬದಲಿಸುವ ಬದಲು ಅದರ ಮಾರ್ಗ, ದೃಢೀಕರಣ ಮತ್ತು ದೀರ್ಘಕಾಲ ಉಳಿಯುವ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಅನುಸರಿಸಿ.