Zergatik SockJS proxy-akatsak fallbackaren ondoren soilik ager daitezkeen
WebSocket bideak eta XHR fallbackak HTTP bezero ezberdinak erabil ditzakete. Proxy ezarpenak aldatu aurretik, identifikatu huts egiten duen garraioa.
WebSocket sare batean funtzionatzen duenean baina SockJS beste batean huts egiten duenean, baliteke bigarren sareak XHR fallbacka abiarazi izana. Horrek eskaerak egiten dituen HTTP inplementazioa alda dezake — eta, beraz, erabiltzen den proxy konfigurazioa ere bai.
Kokatu huts egin zuen lehen URLa eta hark aukeratutako garraioa. SockJS-k HTTP informazio-eskaera bat egin dezake garraioa aukeratu aurretik; WebSocket handshakea eta ondorengo polling eskaerak eragiketa bereiziak dira. Funtzionatzen duen handshake konfigurazioak ez du bakoitzerako erabilitako bidea frogatzen.
Spring-en Java bezeroan, RestTemplateXhrTransport-k konfiguratutako RestTemplate bat onartzen du. Bere eskaera-fabrikak eta azpiko HTTP bezeroak fallbackak onartzen duen proxy bidea eta autentifikazioa ematen dituzte. Spring 6 eta HttpClient 5 erabiliz gero, konfiguratu RestTemplate horren benetako eskaera-fabrika. Inplementazio horrek Apache HTTP osagaiak erabiltzen baditu, haren belaunaldiak integrazioarekin bat etorri behar du.
WebSocket bezeroak bere dokumentatutako konexio-ezarpenak ditu. JVM proxy propietateek bide bat ukitzen dute haien bezero zehatzak irakurtzen dituenean soilik. Konparatu funtzionatzen duen eta huts egiten duen ingurunea garraio, bezero inplementazio, aukeratutako proxy eta lehen errorearen arabera. XHR soilik huts egiten badu, jarraitu haren bidea, autentifikazioa eta denbora luzeko erantzunak, funtzionatzen duen WebSocket bezeroaren ezarpenak behin eta berriz aldatu ordez.