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 ક્લાયન્ટની સેટિંગ્સ વારંવાર બદલવાને બદલે તેના માર્ગ, પ્રમાણીકરણ અને લાંબા સમય સુધી ટકતા પ્રતિભાવોને અનુસરો.