ଏକ ଫରୱାର୍ଡ ପ୍ରକ୍ସି ଏକ କଷ୍ଟମ API ହେଡରକୁ କିପରି ପରିଚାଳନା କରେ

ଏକ API ନିଜ ସଂସ୍କରଣକୁ API-Version ପରି କଷ୍ଟମ ଅନୁରୋଧ କ୍ଷେତ୍ରରେ ବହନ କରିପାରେ। ସାଧାରଣ ଫରୱାର୍ଡିଂ ପ୍ରକ୍ସି କେବଳ ନାମ ଅପରିଚିତ ବୋଲି ସେହି କ୍ଷେତ୍ରକୁ ବାହାର କରିଦେବା ଉଚିତ ନୁହେଁ। HTTP ଅପରିଚିତ କ୍ଷେତ୍ରଗୁଡ଼ିକୁ ଫରୱାର୍ଡ କରିବା ବାଧ୍ୟତାମୂଳକ କରେ, ଯଦି କୌଣସି ନିର୍ଦ୍ଦିଷ୍ଟ ବ୍ୟତିକ୍ରମ କିମ୍ବା ବିନ୍ୟାସିତ ନୀତି ଲାଗୁ ନ ହୁଏ।

Connection କ୍ଷେତ୍ର ସେହିପରି ଏକ ବ୍ୟତିକ୍ରମ। ଏହି ଉଦାହରଣ ଅନୁରୋଧଗୁଡ଼ିକୁ ତୁଳନା କରନ୍ତୁ:

API-Version: 2026-10
Connection: keep-alive

ଏଠାରେ API କ୍ଷେତ୍ର ଏହି ସଂଯୋଗ ପାଇଁ ସ୍ଥାନୀୟ ଭାବରେ ନିର୍ଦ୍ଦିଷ୍ଟ କରାଯାଇ ନାହିଁ। ପରବର୍ତ୍ତୀ ଉଦାହରଣରେ ପ୍ରେରକ ସ୍ପଷ୍ଟ ଭାବରେ ଏହାର ପରିସର ବଦଳାଉଛି:

API-Version: 2026-10
Connection: API-Version

ଫରୱାର୍ଡିଂ ପ୍ରକ୍ସି ଫରୱାର୍ଡ କରିବା ପୂର୍ବରୁ Connection ଦ୍ୱାରା ନାମିତ କ୍ଷେତ୍ରଗୁଡ଼ିକୁ ଅପସାରଣ କରେ ଏବଂ ସଂଯୋଗ-ନିର୍ଦ୍ଦିଷ୍ଟ ନିର୍ଦ୍ଦେଶଗୁଡ଼ିକୁ ନିଜେ ଅପସାରଣ କିମ୍ବା ପ୍ରତିସ୍ଥାପନ କରେ। ତେଣୁ ମୂଳ ଉତ୍ସ ପାଇଁ ଉଦ୍ଦିଷ୍ଟ ଆପ୍ଲିକେସନ ହେଡର ସେହି ଟୋକେନ ତାଲିକାରେ ରହିବା ଉଚିତ ନୁହେଁ।

କ୍ଷେତ୍ର ଯେଉଁଠାରେ ବଦଳେ ସେହି ବିନ୍ଦୁ ଖୋଜନ୍ତୁ

କ୍ଲାଏଣ୍ଟ ତିଆରି କରିଥିବା ଅନୁରୋଧ, ପ୍ରକ୍ସି ଗ୍ରହଣ କରି ଫରୱାର୍ଡ କରିଥିବା କ୍ଷେତ୍ର, ଏବଂ ମୂଳ ଉତ୍ସ କଣ ପାଇଲା ତୁଳନା କରନ୍ତୁ। କ୍ଲାଏଣ୍ଟ ପ୍ରକ୍ସି ଦେଖିବା ପୂର୍ବରୁ ଏକ ହେଡର ଛାଡ଼ିପାରେ; ବିନ୍ୟାସିତ ଫିଲ୍ଟର ଏହାକୁ ଜାଣିଶୁଣି ଅପସାରଣ କରିପାରେ; ସର୍ଭର ହେଡର ସୀମା ଅତିକ୍ରମ କରିଥିବାରୁ ଅନୁରୋଧକୁ ପ୍ରତ୍ୟାଖ୍ୟାନ କରିପାରେ।

ପୁରୁଣା ନିୟୋଜନରେ ରିପୋର୍ଟ କରାଯାଇଥିବା ହେଡର ଆକାର ସୀମାରୁ କେବଳ ନୀରବ ଅପସାରଣ ଅନୁମାନ କରନ୍ତୁ ନାହିଁ। ସୀମା ଏବଂ ପ୍ରତ୍ୟାଖ୍ୟାନ ଆଚରଣ ପ୍ରକୃତ ଉପାଦାନ ଏବଂ ବିନ୍ୟାସ ସହିତ ସମ୍ବନ୍ଧିତ। HTTP ପ୍ରତିକ୍ରିୟା ଏବଂ ସମ୍ପୃକ୍ତ ଲଗ ପର୍ଯ୍ୟବେକ୍ଷଣ ସହିତ ରଖନ୍ତୁ।

ସାଧାରଣ CONNECT ଟନେଲ ଭିତରେ ଏଣ୍ଡ-ଟୁ-ଏଣ୍ଡ HTTPS ହେଲେ ପ୍ରକ୍ସି ଭିତରର API କ୍ଷେତ୍ର ପଢ଼ି ଓ ବାଛି ଅପସାରଣ କରିପାରିବ ନାହିଁ। ସେତେବେଳେ ହେଡର ଯାଞ୍ଚ TLS ପ୍ରାନ୍ତରେ କିମ୍ବା ସ୍ପଷ୍ଟ ଭାବରେ ବିଶ୍ୱସ୍ତ ଯାଞ୍ଚ ମଧ୍ୟସ୍ଥ ପାଖରେ ରହେ।