Pam y gall methiant procsi SockJS ymddangos dim ond ar ôl y cwymp-bell
Gall llwybr WebSocket a'r cwymp-bell XHR ddefnyddio cleientiaid HTTP gwahanol. Nodwch y trafnidiaeth sy'n methu cyn newid ei osodiadau procsi.
Pan fydd WebSocket yn gweithio ar un rhwydwaith ond SockJS yn methu ar un arall, efallai bod yr ail rwydwaith wedi sbarduno'r cwymp-bell XHR. Gall hynny newid yr HTTP implementation sy'n gwneud y ceisiadau — ac felly'r ffurfwedd procsi a ddefnyddir.
Dewch o hyd i'r URL cyntaf a fethodd a'r drafnidiaeth a ddewiswyd ganddo. Gall SockJS wneud cais gwybodaeth HTTP cyn dewis trafnidiaeth; mae'r WebSocket handshake a'r ceisiadau pleidleisio dilynol yn weithrediadau ar wahân. Nid yw ffurfwedd handshake sy'n gweithio yn profi'r llwybr a ddefnyddir ar gyfer pob un ohonynt.
Yng nghleient Java Spring, mae RestTemplateXhrTransport yn derbyn RestTemplate wedi'i ffurfweddu. Mae ei ffatri ceisiadau a'r HTTP cleient sylfaenol yn darparu llwybr procsi a dilysiad a gefnogir gan y cwymp-bell. Ar gyfer Spring 6 gyda HttpClient 5, ffurfweddwch ffatri ceisiadau gwirioneddol y RestTemplate hwnnw. Os yw'r implementation honno'n defnyddio cydrannau Apache HTTP, rhaid i'w genhedlaeth gyd-fynd â'r integreiddiad.
Mae gan y cleient WebSocket ei osodiadau cysylltu dogfennedig ei hun. Dim ond os yw ei gleient penodol yn eu darllen y mae priodweddau procsi JVM yn effeithio ar lwybr. Cymharwch yr amgylcheddau sy'n gweithio ac sy'n methu yn ôl trafnidiaeth, implementation y cleient, y procsi a ddewiswyd a'r camgymeriad cyntaf. Os mai dim ond XHR sy'n methu, dilynwch ei lwybr, ei ddilysiad a'i ymatebion hir eu cyfnod yn lle newid gosodiadau'r cleient WebSocket sy'n gweithio dro ar ôl tro.