Чому збій проксі 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.