HTTP CONNECT ଉତ୍ତର ପରେ ବଫର ହୋଇଥିବା ଡାଟା ସଂରକ୍ଷିତ ରଖନ୍ତୁ

ଏକ ଛୋଟ ପ୍ରକ୍ସି ର୍ୟାପର HTTPS ପାଇଁ କାମ କରିପାରେ ଏବଂ ପରେ ଏପରି ପ୍ରୋଟୋକଲ ପାଇଁ ପୁନଃ ବ୍ୟବହାର ହେଲେ ଅଟକି ଯାଇପାରେ ଯାହାର ସର୍ଭର ପ୍ରଥମେ କଥା କହେ। ସନ୍ଦେହଜନକ ଧାଡ଼ି ସାଧାରଣତଃ ସେହି ଧାଡ଼ି ଯାହା ଗ୍ରହଣ ବଫର \r\n\r\n ସହିତ ଶେଷ ହେବାକୁ ଅପେକ୍ଷା କରେ।

TCP କ୍ଲାଏଣ୍ଟକୁ ଏକ ଷ୍ଟ୍ରିମ ଦିଏ। ଏକ ଗ୍ରହଣ କଲ ଅଧା HTTP ଷ୍ଟାଟସ ଧାଡ଼ି, ସମ୍ପୂର୍ଣ୍ଣ CONNECT ଉତ୍ତର, କିମ୍ବା ସେହି ଉତ୍ତର ସହିତ ତୁରନ୍ତ ଟନେଲ ଡାଟା ଫେରାଇପାରେ। ପଠନ ହେଡରର ଶେଷରେ ଅଟକିବ ବୋଲି କୌଣସି ପ୍ରତିଶ୍ରୁତି ନାହିଁ।

ବଫର ଭିତରେ ସୀମା ଖୋଜନ୍ତୁ

HTTP/1.1 CONNECT ବିନିମୟ ପାଇଁ, ହେଡର ସମାପ୍ତି ଚିହ୍ନ ବଫରରେ ଯେକୌଣସି ସ୍ଥାନରେ ଦେଖାଯିବା ପର୍ଯ୍ୟନ୍ତ ବାଇଟ ସଂଗ୍ରହ କରନ୍ତୁ। ଏହାର ପ୍ରଥମ ଘଟଣାରେ ବିଭାଜନ କରନ୍ତୁ। ପ୍ରଥମ ଅଂଶରୁ ଷ୍ଟାଟସ ଧାଡ଼ି ଏବଂ ହେଡର ପାର୍ସ କରନ୍ତୁ; ସୀମା ପରେ ସବୁକିଛି ଅଲଗା ରଖନ୍ତୁ। ଅପେକ୍ଷା ସମୟରେ ହେଡର ଆକାର ସୀମା ଏବଂ ସମୟ ସୀମା ଲାଗୁ କରନ୍ତୁ, ଏବଂ ଖାଲି ସକେଟ ପଠନକୁ ଲୁପକୁ ଯିବାର ଆଉ ଏକ ନିମନ୍ତ୍ରଣ ନ ମାନି ବନ୍ଦ ସଂଯୋଗ ମାନନ୍ତୁ।

ଅନ୍ତିମ ସଫଳ 2xx ଉତ୍ତର ସେହି ହେଡର ପରେ ତୁରନ୍ତ ସଂଯୋଗକୁ ଟନେଲ ମୋଡକୁ ବଦଳାଏ। ଏହା ପରେ ଆସୁଥିବା ବାଇଟ ପୂର୍ବରୁ ଟନେଲ ବାଇଟ। ସେଗୁଡ଼ିକୁ ଫିଙ୍ଗନ୍ତୁ ନାହିଁ, CONNECT ଉତ୍ତର ବଡି ପାଇଁ ଅପେକ୍ଷା କରନ୍ତୁ ନାହିଁ, ଏବଂ Content-Length ଫିଲ୍ଡକୁ ନୂଆ ପ୍ରୋଟୋକଲର ଏକ ଅଂଶ ବ୍ୟବହାର କରିବାର ଅନୁମତି ଭାବେ ବୁଝନ୍ତୁ ନାହିଁ। ସୂଚନାତ୍ମକ ଉତ୍ତର ଥିଲେ ସେଗୁଡ଼ିକ ସେହି ଅନ୍ତିମ ଉତ୍ତର ପୂର୍ବରୁ ସମ୍ଭାଳିବା ଆବଶ୍ୟକ।

ର୍ୟାପର ଏହାର ଅବଶିଷ୍ଟ ଆଗକୁ ପଠାଇବା ଆବଶ୍ୟକ

କେବଳ ଅନ୍ତର୍ନିହିତ ସକେଟ ଫେରାଇଲେ ହ୍ୟାଣ୍ଡସେକ ପାର୍ସର ପୂର୍ବରୁ ତାହାରୁ ବାହାର କରିଥିବା ବାଇଟ ହଜିଯାଏ। ପରବର୍ତ୍ତୀ ପାଠକକୁ ଏପରି ଏକ ବଫର କରାଯାଇଥିବା ଷ୍ଟ୍ରିମ ଦରକାର ଯାହା ପ୍ରଥମେ ସଞ୍ଚିତ ଲାଞ୍ଜ ଦିଏ ଏବଂ ପରେ ସକେଟ ପଠନ ପୁନଃ ଆରମ୍ଭ କରେ। ସର୍ଭର-ପ୍ରଥମ ପ୍ରୋଟୋକଲ ପାଇଁ ସେହି ପ୍ରାରମ୍ଭିକ ଅଭିବାଦନ ହରାଇବା ଦ୍ୱାରା ଉଭୟ ପକ୍ଷ ଅସୀମିତ ଅପେକ୍ଷା କରିପାରନ୍ତି।

ଓଲଟା ଭାବରେ, ବିଫଳ CONNECT ଉତ୍ତରର ବାଇଟ ଟନେଲ ଅଭିବାଦନ ନୁହେଁ। 407 ଏବେ ମଧ୍ୟ ପ୍ରକ୍ସି ବିନିମୟର ଅଟେ ଏବଂ ପ୍ରମାଣୀକରଣ ସମ୍ଭାଳିବା ଆବଶ୍ୟକ; ଅନ୍ୟ ଅସଫଳ ସ୍ଥିତି ପାଇଁ ଉପଯୁକ୍ତ ତ୍ରୁଟି ପଥ ଦରକାର।

ଏହା ବିଶେଷକରି HTTP ପ୍ରକ୍ସି ମାଧ୍ୟମରେ FTP କିମ୍ବା SSH କ୍ଲାଏଣ୍ଟ ଅନୁକୂଳ କରିବା ସମୟରେ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। ପ୍ରକ୍ସିକୁ ମଧ୍ୟ ଅନୁରୋଧିତ ଗନ୍ତବ୍ୟ ପୋର୍ଟକୁ ଅନୁମତି ଦେବାକୁ ପଡ଼େ, ଏବଂ FTP କୁ ଅତିରିକ୍ତ ଡାଟା ସଂଯୋଗ ଦରକାର ହୋଇପାରେ। ସଠିକ୍ ହେଡର ପାର୍ସିଂ ଷ୍ଟ୍ରିମ ହସ୍ତାନ୍ତରଣ ସମାଧାନ କରେ; ଏହା CONNECT ଅନୁମତି ଦେଇପାରେ ନାହିଁ କିମ୍ବା FTPର ଦ୍ୱିତୀୟ ଚ୍ୟାନେଲ ଯୋଗାଇପାରେ ନାହିଁ।