ଫରୱାର୍ଡ ପ୍ରକ୍ସି ଅନୁରୋଧ ଧାଡି ଓ ହେଡର ପଢ଼େ, ସେଗୁଡ଼ିକୁ ପଠାଏ, ତାପରେ select ରେ POST ବଡି ପାଇଁ ଅପେକ୍ଷା କରେ। କ୍ଲାଏଣ୍ଟ ଏହାକୁ ଆଗରୁ ପଠାଇ ସାରିଛି। ଉଭୟ ପକ୍ଷ ପରସ୍ପରକୁ ଅପେକ୍ଷା କରୁଥିବା ପରି ଦେଖାଯାଉଛି।

Python ର BaseHTTPRequestHandler ସହିତ, ହେଡର ପଢ଼ିବା rfile ଦେଇ ଯାଏ, ଯାହା ଏକ ବଫର ହୋଇଥିବା ଇନପୁଟ ଷ୍ଟ୍ରିମ। ସେହି ଷ୍ଟ୍ରିମ ଆଗକୁ ପଢ଼ିପାରେ ଏବଂ ବଡିର ବାଇଟ ଧରି ରଖିପାରେ। ତଳର socket ଉପରେ ଅପେକ୍ଷା କରିବା କେବଳ ଏହାର ଫାଇଲ ଡିସ୍କ୍ରିପ୍ଟର ପ୍ରସ୍ତୁତ କି ନାହିଁ ପଚାରେ; Python ଷ୍ଟ୍ରିମରେ ଆଗରୁ ବ୍ୟବହାରଯୋଗ୍ୟ ଡାଟା ଅଛି କି ନାହିଁ ପଚାରେ ନାହିଁ।

ହେଡର ପଢ଼ିଥିବା ବଫରକୁ ଅନୁସରଣ କରନ୍ତୁ

ବଡି ମଧ୍ୟ self.rfile ଦେଇ ପଢ଼ନ୍ତୁ। ବଫର ହୋଇଥିବା ଷ୍ଟ୍ରିମ ସହିତ ହେଡର ପାର୍ସ କରିବା ପରେ self.connection.recv କୁ ଯିବେ ନାହିଁ। ନହେଲେ କୋଡ ସେହି ଷ୍ଟ୍ରିମ ଧରି ରଖିଥିବା ବାଇଟ ଛାଡ଼ି ପୁଣି କେବେ ନପଠାଯିବା ଡାଟା ପାଇଁ ଅପେକ୍ଷା କରିପାରେ।

rfile ନିଜକୁ select କୁ ଦେବା ଦ୍ୱାରା select ଏହାର Python ବଫର ଯାଞ୍ଚ କରେ ନାହିଁ। ପ୍ରସ୍ତୁତତା API ବସ୍ତୁର ଫାଇଲ ଡିସ୍କ୍ରିପ୍ଟର ଦେଇ କାର୍ଯ୍ୟ କରେ।

ଏକ ବୈଧ Content-Length ଥିବା ଏବଂ Transfer-Encoding ନଥିବା ଅନୁରୋଧ ପାଇଁ, ଘୋଷିତ ବାଇଟ ସଂଖ୍ୟା ଠିକ ସେତିକି ବ୍ୟବହାର କରନ୍ତୁ, ଇନପୁଟର ଅକାଳ ସମାପ୍ତି ଏବଂ ଆପଣଙ୍କ ଆକାର ଓ ସମୟ ସୀମା ସମ୍ଭାଳନ୍ତୁ। EOF ପର୍ଯ୍ୟନ୍ତ ପଢ଼ନ୍ତୁ ନାହିଁ: ସ୍ଥାୟୀ ସଂଯୋଗ ବ୍ୟବହାର କରୁଥିବା କ୍ଲାଏଣ୍ଟ ଅନୁରୋଧ ସମାପ୍ତ ପରେ ମଧ୍ୟ ସଂଯୋଗ ଖୋଲା ରଖିପାରେ।

ଫ୍ରେମିଂକୁ ପ୍ରକ୍ସିର ସ୍ପଷ୍ଟ ଅଂଶ କରନ୍ତୁ

ଚଙ୍କଡ ଅନୁରୋଧ ବଡି ପାଇଁ ଚଙ୍କଡ ଫ୍ରେମିଂ ସମର୍ଥନ ଦରକାର। ଅନୁପସ୍ଥିତ Content-Length ଖୋଜି ସେଗୁଡ଼ିକୁ ପଢ଼ାଯାଇପାରିବ ନାହିଁ। ଅସ୍ପଷ୍ଟ ଲମ୍ବା ମେଟାଡାଟା ପାଇଁ ସୁବିଧାଜନକ ଦେଖାଯାଉଥିବା ହେଡର ବାଛିବା ପରିବର୍ତ୍ତେ ନିର୍ଦ୍ଦିଷ୍ଟ ପ୍ରତ୍ୟାଖ୍ୟାନ ପଥ ଦରକାର।

ବ୍ଲକିଂ handler ସୀମିତ ପଠନ ସହିତ ଏହାର ଷ୍ଟ୍ରିମ ଇଣ୍ଟରଫେସ ବ୍ୟବହାର ଜାରି ରଖିପାରେ। ଇଭେଣ୍ଟ-ଚାଳିତ ପ୍ରକ୍ସି ପାଇଁ ଏପରି ବଫର ମଡେଲ ଦରକାର ଯାହା ପାର୍ସରର ଆଗୁଆ ପଠନକୁ ପ୍ରସ୍ତୁତତା ପରିଚାଳନା ସହିତ ସଂଯୋଜିତ କରେ। ଟାଇମଆଉଟ ବଦଳାଇବା ଦ୍ୱାରା ଏକ ହିଁ socketର ଦୁଇ ସ୍ୱାଧୀନ ଗ୍ରାହକ ମିଳିବେ ନାହିଁ।

ଏହି ନିର୍ଣ୍ଣୟ ଆସୁଥିବା ବାଇଟ କେଉଁଠି ରଖାଯାଏ ସେ ବିଷୟରେ ନିର୍ଦ୍ଦିଷ୍ଟ। ପ୍ରକ୍ସି ସଠିକ ବଡି ବ୍ୟବହାର କରିବା ପରେ ମଧ୍ୟ ସେହି ବଡିକୁ ସଙ୍ଗତ HTTP ଫ୍ରେମିଂ ସହିତ ପଠାଇବାକୁ ପଡ଼େ। ମାନକ http.server handler ଯାନ୍ତ୍ରିକତା ବୁଝିବା ପାଇଁ ଉପଯୋଗୀ ସ୍ଥାନ, କିନ୍ତୁ ଏହା ଉତ୍ପାଦନ ଫରୱାର୍ଡ-ପ୍ରକ୍ସି କାର୍ଯ୍ୟାନ୍ୱୟନ ନୁହେଁ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ