Kwa nini hitilafu ya proksi ya SockJS inaweza kuonekana tu baada ya njia mbadala
Njia ya WebSocket na njia mbadala ya XHR zinaweza kutumia wateja tofauti wa HTTP. Tambua usafiri unaoshindwa kabla ya kubadilisha mipangilio yake ya proksi.
Wakati WebSocket inafanya kazi kwenye mtandao mmoja lakini SockJS inashindwa kwenye mwingine, mtandao wa pili unaweza kuwa umeanzisha njia mbadala ya XHR. Hiyo inaweza kubadilisha utekelezaji wa HTTP unaofanya maombi — na hivyo usanidi wa proksi unaotumika.
Tafuta URL ya kwanza iliyoshindwa na usafiri uliochaguliwa nayo. SockJS inaweza kufanya ombi la taarifa la HTTP kabla ya kuchagua usafiri; mshikamano wa WebSocket na maombi ya upigaji kura yanayofuata ni shughuli tofauti. Usanidi wa mshikamano unaofanya kazi hauthibitishi njia inayotumika kwa kila moja yao.
Katika mteja wa Java wa Spring, RestTemplateXhrTransport hukubali RestTemplate iliyosanidiwa. Kiwanda chake cha maombi na mteja msingi wa HTTP hutoa njia ya proksi na uthibitishaji unaoungwa mkono na njia mbadala. Kwa Spring 6 pamoja na HttpClient 5, sanidi kiwanda halisi cha maombi cha RestTemplate hiyo. Ikiwa utekelezaji huo unatumia vipengele vya Apache HTTP, kizazi chake lazima kilingane na muunganisho.
Mteja wa WebSocket ana mipangilio yake ya muunganisho iliyoandikwa. Sifa za proksi za JVM huathiri njia ikiwa tu mteja wake mahususi anazisoma. Linganisha mazingira yanayofanya kazi na yanayoshindwa kwa usafiri, utekelezaji wa mteja, proksi iliyochaguliwa na hitilafu ya kwanza. Ikiwa XHR pekee inashindwa, fuata njia yake, uthibitishaji wake na majibu yake yanayodumu kwa muda mrefu badala ya kubadilisha mara kwa mara mipangilio ya mteja wa WebSocket unaofanya kazi.