SockJS проксинин катасы эмне үчүн резервдик жолго өткөндөн кийин гана көрүнүшү мүмкүн
WebSocket жолу жана XHR резервдик жолу ар кандай HTTP кардарларын колдонушу мүмкүн. Прокси жөндөөлөрүн өзгөртүүдөн мурун кайсы транспорт иштебей жатканын аныктаңыз.
Бир тармакта WebSocket иштеп, экинчисинде SockJS иштебей калса, экинчи тармак XHR резервдик жолун иштеткен болушу мүмкүн. Бул сурамдарды аткарган HTTP ишке ашыруусун — демек, колдонулган прокси конфигурациясын да өзгөртүшү мүмкүн.
Биринчи иштебей калган URL жана анын тандаган транспортун табыңыз. SockJS транспорт тандоодон мурун HTTP маалыматтык сурамын жасоосу мүмкүн; WebSocket кол алышуусу жана кийинки сурам суроолору өзүнчө операциялар. Иштеген кол алышуу конфигурациясы алардын ар бири үчүн колдонулган жолду далилдебейт.
Spring'дин Java кардарында RestTemplateXhrTransport конфигурацияланган RestTemplate кабыл алат. Анын сурам фабрикасы жана негизги HTTP кардары резервдик жол колдогон прокси маршрутун жана аутентификацияны камсыз кылат. Spring 6 жана HttpClient 5 үчүн ошол RestTemplate'тин чыныгы сурам фабрикасын конфигурациялаңыз. Эгер бул ишке ашыруу Apache HTTP компоненттерин колдонсо, анын мууну интеграцияга дал келиши керек.
WebSocket кардарынын өзүнүн документтелген туташуу жөндөөлөрү бар. JVM прокси касиеттери жолго анын конкреттүү кардары аларды окуганда гана таасир этет. Иштеген жана иштебей жаткан чөйрөлөрдү транспорт, кардар ишке ашыруусу, тандалган прокси жана биринчи ката боюнча салыштырыңыз. Эгер XHR гана иштебей жатса, иштеп жаткан WebSocket кардарынын жөндөөлөрүн кайра-кайра өзгөртүүнүн ордуна анын маршрутун, аутентификациясын жана узак сакталган жоопторун ээрчиңиз.