Miksi SockJS-välityspalvelinvirhe voi näkyä vasta varayhteyden jälkeen
WebSocket-reitti ja XHR-varayhteys voivat käyttää eri HTTP-asiakkaita. Tunnista epäonnistuva siirto ennen sen välityspalvelinasetusten muuttamista.
Kun WebSocket toimii yhdessä verkossa mutta SockJS epäonnistuu toisessa, toinen verkko on saattanut käynnistää XHR-varayhteyden. Se voi muuttaa pyynnöt tekevää HTTP-toteutusta — ja siten käytettävää välityspalvelinmääritystä.
Paikanna ensimmäinen epäonnistunut URL ja sen valitsema siirto. SockJS voi tehdä HTTP-tietopyynnön ennen siirron valintaa; WebSocket-kättely ja sitä seuraavat kyselypyynnöt ovat erillisiä toimintoja. Toimiva kättelymääritys ei todista kummallekin käytettyä reittiä.
Springin Java-asiakkaassa RestTemplateXhrTransport hyväksyy määritetyn RestTemplate-olion. Sen pyyntötehdas ja taustalla oleva HTTP-asiakas tarjoavat varayhteyden tukeman välityspalvelinreitin ja todennuksen. Spring 6:ssa HttpClient 5:n kanssa määritä kyseisen RestTemplate-olion todellinen pyyntötehdas. Jos tämä toteutus käyttää Apache HTTP -komponentteja, sen sukupolven on vastattava integraatiota.
WebSocket-asiakkaalla on omat dokumentoidut yhteysasetuksensa. JVM:n välityspalveluominaisuudet vaikuttavat reittiin vain, jos sen konkreettinen asiakas lukee ne. Vertaa toimivaa ja epäonnistuvaa ympäristöä siirron, asiakastoteutuksen, valitun välityspalvelimen ja ensimmäisen virheen mukaan. Jos vain XHR epäonnistuu, seuraa sen reittiä, todennusta ja pitkäkestoisia vastauksia sen sijaan, että muuttaisit toistuvasti toimivan WebSocket-asiakkaan asetuksia.