Hoekom 'n SockJS-volmagfout eers ná terugval kan verskyn
Die WebSocket-roete en 'n XHR-terugval kan verskillende HTTP-kliënte gebruik. Identifiseer die mislukte vervoer voordat jy sy volmaginstellings verander.
Wanneer WebSocket op een netwerk werk maar SockJS op 'n ander misluk, het die tweede netwerk moontlik XHR-terugval geaktiveer. Dit kan die HTTP-implementering verander wat die versoeke maak—en dus die volmagkonfigurasie wat gebruik word.
Spoor die eerste mislukte URL en sy gekose vervoer op. SockJS kan 'n HTTP-inligtingsversoek maak voordat dit 'n vervoer kies; die WebSocket-handdruk en daaropvolgende peilversoeke is afsonderlike bewerkings. 'n Werkende handdrukkonfigurasie bepaal nie die roete wat vir elkeen gebruik word nie.
In Spring se Java-kliënt aanvaar RestTemplateXhrTransport 'n gekonfigureerde RestTemplate. Sy versoekfabriek en onderliggende HTTP-kliënt verskaf die terugval se ondersteunde volmagroete en -verifikasie. Vir Spring 6 met HttpClient 5, konfigureer daardie RestTemplate se werklike versoekfabriek. As daardie implementering Apache HTTP-komponente gebruik, moet sy generasie by die integrasie pas.
Die WebSocket-kliënt het sy eie gedokumenteerde verbindingsinstellings. JVM-volmageienskappe beïnvloed 'n roete net as sy konkrete kliënt dit lees. Vergelyk die werkende en mislukte omgewings per vervoer, kliëntimplementering, gekose volmag en eerste fout. As net XHR misluk, volg sy roete, verifikasie en langdurige response in plaas daarvan om die werkende WebSocket-kliënt se instellings herhaaldelik te verander.