რატომ შეიძლება SockJS პროქსის ხარვეზი მხოლოდ სარეზერვო გზის შემდეგ გამოჩნდეს

როცა WebSocket ერთ ქსელში მუშაობს, მაგრამ SockJS მეორეში ფუჭდება, შესაძლოა მეორე ქსელმა XHR სარეზერვო გზა ჩართო. ამან შეიძლება შეცვალოს მოთხოვნების შემსრულებელი HTTP იმპლემენტაცია — და, შესაბამისად, გამოყენებული პროქსის კონფიგურაციაც.

იპოვეთ პირველი წარუმატებელი URL და მის მიერ არჩეული ტრანსპორტი. SockJS-მა შეიძლება HTTP საინფორმაციო მოთხოვნა გაგზავნოს ტრანსპორტის არჩევამდე; WebSocket-ის ხელის ჩამორთმევა და შემდგომი გამოკითხვის მოთხოვნები ცალკეული ოპერაციებია. მომუშავე ხელის ჩამორთმევის კონფიგურაცია არ ამტკიცებს თითოეული მათგანისთვის გამოყენებულ გზას.

Spring-ის Java კლიენტში RestTemplateXhrTransport იღებს კონფიგურირებულ RestTemplate-ს. მისი მოთხოვნების ფაბრიკა და ქვედა HTTP კლიენტი უზრუნველყოფენ სარეზერვო გზის მიერ მხარდაჭერილ პროქსის მარშრუტსა და აუთენტიფიკაციას. Spring 6-ისთვის HttpClient 5-ით, კონფიგურირეთ იმ RestTemplate-ის ფაქტობრივი მოთხოვნების ფაბრიკა. თუ ეს იმპლემენტაცია იყენებს Apache HTTP კომპონენტებს, მისი თაობა უნდა შეესაბამებოდეს ინტეგრაციას.

WebSocket კლიენტს აქვს საკუთარი დოკუმენტირებული კავშირის პარამეტრები. JVM პროქსის თვისებები გზაზე მოქმედებს მხოლოდ მაშინ, როცა მისი კონკრეტული კლიენტი კითხულობს მათ. შეადარეთ მომუშავე და წარუმატებელი გარემოები ტრანსპორტის, კლიენტის იმპლემენტაციის, არჩეული პროქსისა და პირველი შეცდომის მიხედვით. თუ მხოლოდ XHR ფუჭდება, მიჰყევით მის მარშრუტს, აუთენტიფიკაციასა და ხანგრძლივ პასუხებს, ნაცვლად იმისა, რომ განმეორებით შეცვალოთ მომუშავე WebSocket კლიენტის პარამეტრები.