SockJS ପ୍ରକ୍ସି ବିଫଳତା କେବଳ ଫଲବ୍ୟାକ୍ ପରେ କାହିଁକି ଦେଖାଯାଇପାରେ

ଯେତେବେଳେ ଏକ ନେଟୱାର୍କରେ WebSocket କାର୍ଯ୍ୟ କରେ କିନ୍ତୁ ଅନ୍ୟଟିରେ SockJS ବିଫଳ ହୁଏ, ସେତେବେଳେ ଦ୍ୱିତୀୟ ନେଟୱାର୍କ XHR ଫଲବ୍ୟାକ୍ ଆରମ୍ଭ କରିଥାଇପାରେ। ଏହା ଅନୁରୋଧ କରୁଥିବା HTTP କାର୍ଯ୍ୟାନ୍ୱୟନକୁ ବଦଳାଇପାରେ — ଏବଂ ସେଥିପାଇଁ ବ୍ୟବହୃତ ପ୍ରକ୍ସି କନଫିଗରେସନ୍ ମଧ୍ୟ।

ପ୍ରଥମ ବିଫଳ URL ଏବଂ ଏହାର ଚୟନିତ ଟ୍ରାନ୍ସପୋର୍ଟ ଖୋଜନ୍ତୁ। SockJS ଟ୍ରାନ୍ସପୋର୍ଟ ବାଛିବା ପୂର୍ବରୁ ଏକ HTTP ସୂଚନା ଅନୁରୋଧ କରିପାରେ; WebSocket ହ୍ୟାଣ୍ଡସେକ୍ ଏବଂ ପରବର୍ତ୍ତୀ ପୋଲିଂ ଅନୁରୋଧ ଅଲଗା କାର୍ଯ୍ୟ। କାର୍ଯ୍ୟକ୍ଷମ ହ୍ୟାଣ୍ଡସେକ୍ କନଫିଗରେସନ୍ ସେମାନଙ୍କ ପ୍ରତ୍ୟେକ ପାଇଁ ବ୍ୟବହୃତ ପଥ ପ୍ରମାଣ କରେ ନାହିଁ।

Spring ର Java କ୍ଲାଏଣ୍ଟରେ RestTemplateXhrTransport ଏକ କନଫିଗର ହୋଇଥିବା RestTemplate ଗ୍ରହଣ କରେ। ଏହାର ଅନୁରୋଧ ଫ୍ୟାକ୍ଟ୍ରି ଏବଂ ଅନ୍ତର୍ନିହିତ HTTP କ୍ଲାଏଣ୍ଟ ଫଲବ୍ୟାକ୍ ଦ୍ୱାରା ସମର୍ଥିତ ପ୍ରକ୍ସି ପଥ ଏବଂ ପ୍ରମାଣୀକରଣ ପ୍ରଦାନ କରେ। HttpClient 5 ସହିତ Spring 6 ପାଇଁ, ସେହି RestTemplate ର ପ୍ରକୃତ ଅନୁରୋଧ ଫ୍ୟାକ୍ଟ୍ରି କନଫିଗର କରନ୍ତୁ। ଯଦି ସେହି କାର୍ଯ୍ୟାନ୍ୱୟନ Apache HTTP ଉପାଦାନ ବ୍ୟବହାର କରେ, ଏହାର ପିଢ଼ି ଏକୀକରଣ ସହିତ ମେଳ ଖାଇବା ଆବଶ୍ୟକ।

WebSocket କ୍ଲାଏଣ୍ଟର ନିଜର ଦଲିଲଭୁକ୍ତ ସଂଯୋଗ ସେଟିଂ ଅଛି। JVM ପ୍ରକ୍ସି ଗୁଣ ଏକ ପଥକୁ କେବଳ ସେତେବେଳେ ପ୍ରଭାବିତ କରେ ଯେତେବେଳେ ଏହାର ନିର୍ଦ୍ଦିଷ୍ଟ କ୍ଲାଏଣ୍ଟ ସେଗୁଡ଼ିକୁ ପଢ଼େ। କାର୍ଯ୍ୟକ୍ଷମ ଏବଂ ବିଫଳ ପରିବେଶକୁ ଟ୍ରାନ୍ସପୋର୍ଟ, କ୍ଲାଏଣ୍ଟ କାର୍ଯ୍ୟାନ୍ୱୟନ, ଚୟନିତ ପ୍ରକ୍ସି ଏବଂ ପ୍ରଥମ ତ୍ରୁଟି ଦ୍ୱାରା ତୁଳନା କରନ୍ତୁ। ଯଦି କେବଳ XHR ବିଫଳ ହୁଏ, କାର୍ଯ୍ୟକ୍ଷମ WebSocket କ୍ଲାଏଣ୍ଟର ସେଟିଂ ବାରମ୍ବାର ବଦଳାଇବା ପରିବର୍ତ୍ତେ ଏହାର ପଥ, ପ୍ରମାଣୀକରଣ ଏବଂ ଦୀର୍ଘକାଳୀନ ପ୍ରତିକ୍ରିୟା ଅନୁସରଣ କରନ୍ତୁ।