Ինչու 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 հաճախորդի կարգավորումները կրկին ու կրկին փոխելու փոխարեն։