Kāpēc SockJS starpniekservera kļūme var parādīties tikai pēc rezerves ceļa
WebSocket ceļš un XHR rezerves ceļš var izmantot dažādus HTTP klientus. Pirms mainīt starpniekservera iestatījumus, nosakiet, kurš transporta veids neizdodas.
Ja WebSocket darbojas vienā tīklā, bet SockJS neizdodas citā, otrais tīkls, iespējams, ir aktivizējis XHR rezerves ceļu. Tas var mainīt HTTP ieviešanu, kas veic pieprasījumus — un līdz ar to arī izmantoto starpniekservera konfigurāciju.
Atrodiet pirmo neizdevušos URL un tā izvēlēto transporta veidu. SockJS var veikt HTTP informācijas pieprasījumu pirms transporta izvēles; WebSocket rokasspiediens un turpmākie aptaujas pieprasījumi ir atsevišķas darbības. Strādājoša rokasspiediena konfigurācija nepierāda katram no tiem izmantoto ceļu.
Spring Java klientā RestTemplateXhrTransport pieņem konfigurētu RestTemplate. Tā pieprasījumu rūpnīca un pamatā esošais HTTP klients nodrošina rezerves ceļa atbalstīto starpniekservera maršrutu un autentifikāciju. Spring 6 ar HttpClient 5 gadījumā konfigurējiet šī RestTemplate faktisko pieprasījumu rūpnīcu. Ja šī ieviešana izmanto Apache HTTP komponentus, tās paaudzei jāatbilst integrācijai.
WebSocket klientam ir savi dokumentēti savienojuma iestatījumi. JVM starpniekservera rekvizīti ietekmē ceļu tikai tad, ja tā konkrētais klients tos nolasa. Salīdziniet strādājošo un neizdevušos vidi pēc transporta, klienta ieviešanas, izvēlētā starpniekservera un pirmās kļūdas. Ja neizdodas tikai XHR, sekojiet tā maršrutam, autentifikācijai un ilgi turētajām atbildēm, nevis atkārtoti mainiet strādājošā WebSocket klienta iestatījumus.