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 கிளையண்டின் அமைப்புகளை மீண்டும் மீண்டும் மாற்றுவதற்குப் பதிலாக அதன் பாதை, அங்கீகாரம் மற்றும் நீண்ட நேரம் நீடிக்கும் பதில்களைப் பின்பற்றுங்கள்.