Wêrom't in SockJS-proxyflater pas nei de fallback ferskine kin
It WebSocket-paad en in XHR-fallback kinne ferskate HTTP-klanten brûke. Identifisearje it transportsysteem dat mislearret foardat jo syn proxy-ynstellings feroarje.
As WebSocket op ien netwurk wurket mar SockJS op in oar mislearret, hat it twadde netwurk mooglik de XHR-fallback aktivearre. Dat kin de HTTP-ymplemintaasje feroarje dy't de oanfragen docht — en dus ek de brûkte proxy-konfiguraasje.
Fyn de earste mislearre URL en it keazen transportsysteem. SockJS kin in HTTP-ynformaasjeoanfraach dwaan foardat it in transportsysteem kiest; de WebSocket-hansdruk en folgjende polling-oanfragen binne aparte operaasjes. In wurkjende hansdruk-konfiguraasje bewiist net it paad dat foar elk fan harren brûkt wurdt.
Yn Spring syn Java-klant akseptearret RestTemplateXhrTransport in konfigurearre RestTemplate. Syn oanfraachfabryk en ûnderlizzende HTTP-klant leverje it troch de fallback stipe proxy-paad en autentikaasje. Foar Spring 6 mei HttpClient 5 konfigurearje it werklike oanfraachfabryk fan dy RestTemplate. As dy ymplemintaasje Apache HTTP-komponinten brûkt, moat syn generaasje by de yntegraasje passe.
De WebSocket-klant hat syn eigen dokumintearre ferbiningsynstellings. JVM-proxy-eigenskippen beynfloedzje in paad allinnich as syn konkrete klant se lêst. Ferlykje de wurkjende en mislearjende omjouwings op transportsysteem, klantymplemintaasje, keazen proxy en earste flater. As allinnich XHR mislearret, folgje dan syn paad, autentikaasje en lang duorjende antwurden ynstee fan hieltyd de ynstellings fan de wurkjende WebSocket-klant te feroarjen.