Kodėl SockJS tarpinio serverio gedimas gali pasireikšti tik po atsarginio kelio
WebSocket kelias ir XHR atsarginis kelias gali naudoti skirtingus HTTP klientus. Nustatykite, kuris transportas nepavyksta, prieš keisdami jo tarpinio serverio nuostatas.
Kai WebSocket veikia viename tinkle, o SockJS nepavyksta kitame, antroji tinklas galėjo suaktyvinti XHR atsarginį kelią. Tai gali pakeisti HTTP įgyvendinimą, atliekantį užklausas — ir todėl naudojamą tarpinio serverio konfigūraciją.
Raskite pirmą nepavykusį URL ir jo pasirinktą transportą. SockJS gali atlikti HTTP informacijos užklausą prieš pasirinkdamas transportą; WebSocket rankos paspaudimas ir vėlesnės apklausos užklausos yra atskiros operacijos. Veikianti rankos paspaudimo konfigūracija neįrodo kiekvienam jų naudojamo kelio.
Spring Java kliente RestTemplateXhrTransport priima sukonfigūruotą RestTemplate. Jo užklausų gamykla ir pagrindinis HTTP klientas suteikia atsarginio kelio palaikomą tarpinio serverio maršrutą ir autentifikavimą. Spring 6 su HttpClient 5 atveju sukonfigūruokite tikrąją to RestTemplate užklausų gamyklą. Jei šis įgyvendinimas naudoja Apache HTTP komponentus, jo karta turi atitikti integraciją.
WebSocket klientas turi savo dokumentuotas ryšio nuostatas. JVM tarpinio serverio savybės kelį veikia tik tada, kai jo konkretus klientas jas nuskaito. Palyginkite veikiančią ir nepavykstančią aplinką pagal transportą, kliento įgyvendinimą, pasirinktą tarpinį serverį ir pirmą klaidą. Jei nepavyksta tik XHR, sekite jo maršrutą, autentifikavimą ir ilgai laikomus atsakymus, o ne kartotinai keiskite veikiančio WebSocket kliento nuostatas.