Зошто дефектот на SockJS прокси може да се појави само по резервниот пат
Патеката WebSocket и резервната патека XHR може да користат различни HTTP клиенти. Утврдете кој транспорт не успева пред да ги промените неговите поставки за прокси.
Кога WebSocket работи на една мрежа, но SockJS не успева на друга, втората мрежа можеби го активирала резервниот пат XHR. Тоа може да ја промени HTTP имплементацијата што ги извршува барањата — а со тоа и конфигурацијата за прокси што се користи.
Пронајдете го првиот неуспешен URL и неговиот избран транспорт. SockJS може да испрати HTTP информациско барање пред да избере транспорт; ракувањето WebSocket и следните барања за анкетирање се одделни операции. Работна конфигурација на ракување не докажува која патека се користи за секое од нив.
Во Java клиентот на Spring, RestTemplateXhrTransport прифаќа конфигуриран RestTemplate. Неговата фабрика за барања и основниот HTTP клиент ја обезбедуваат патеката за прокси и автентикацијата поддржани од резервниот пат. За Spring 6 со HttpClient 5, конфигурирајте ја вистинската фабрика за барања на тој RestTemplate. Ако таа имплементација користи Apache HTTP компоненти, нејзината генерација мора да одговара на интеграцијата.
WebSocket клиентот има свои документирани поставки за врска. Својствата за прокси на JVM влијаат на патека само ако неговиот конкретен клиент ги чита. Споредете ја работната и неуспешната околина по транспорт, имплементација на клиентот, избран прокси и прва грешка. Ако само XHR не успева, следете ја неговата патека, автентикација и долготрајни одговори наместо постојано да ги менувате поставките на работниот WebSocket клиент.