Kial SockJS-prokura fiasko povas aperi nur post la rezerva vojo
La WebSocket-vojo kaj XHR-rezervvojo povas uzi malsamajn HTTP-klientojn. Identigu la fiaskantan transporton antaŭ ol ŝanĝi ĝiajn prokurajn agordojn.
Kiam WebSocket funkcias en unu reto sed SockJS fiaskas en alia, la dua reto eble ekigis la XHR-rezervvojon. Tio povas ŝanĝi la HTTP-implementaĵon, kiu faras la petojn — kaj sekve la uzatan prokuran agordon.
Trovu la unuan fiaskintan URL-on kaj ĝian elektitan transporton. SockJS povas fari HTTP-informpeton antaŭ ol elekti transporton; la WebSocket-manpremo kaj postaj enketpetoj estas apartaj operacioj. Funkcianta manprema agordo ne pruvas la vojon uzatan por ĉiu el ili.
En la Java-kliento de Spring, RestTemplateXhrTransport akceptas agorditan RestTemplate. Ĝia petfabriko kaj suba HTTP-kliento provizas la prokuran vojon kaj aŭtentikigon subtenatajn de la rezervvojo. Por Spring 6 kun HttpClient 5, agordu la faktan petfabrikon de tiu RestTemplate. Se tiu implementaĵo uzas Apache HTTP-komponantojn, ĝia generacio devas kongrui kun la integraĵo.
La WebSocket-kliento havas proprajn dokumentitajn konektajn agordojn. JVM-prokuraj ecoj influas vojon nur se ĝia konkreta kliento legas ilin. Komparu la funkciantan kaj fiaskantan mediojn laŭ transporto, klienta implementaĵo, elektita prokuro kaj unua eraro. Se nur XHR fiaskas, sekvu ĝian vojon, aŭtentikigon kaj longdaŭrajn respondojn anstataŭ ripete ŝanĝi la agordojn de la funkcianta WebSocket-kliento.