ଅପଲୋଡ଼କୁ ଖଣ୍ଡରେ ପଢ଼ିବା ପାଇଁ chunked HTTP ଆବଶ୍ୟକ ନାହିଁ

ନା। ଏକ କ୍ଲାଏେଣ୍ଟ ବଡ଼ ଫାଇଲକୁ ଛୋଟ ବଫରରେ ପଢ଼ିପାରେ ଏବଂ ଜଣା Content-Length ସହିତ ପଠାଇପାରେ। ସୀମିତ ପଢ଼ା ମେମୋରୀ ବ୍ୟବହାରକୁ ନିୟନ୍ତ୍ରଣ କରେ; HTTP ଫ୍ରେମିଂ ଗ୍ରାହକକୁ କହେ ଅନୁରୋଧର ବଡି କେଉଁଠି ଶେଷ ହୁଏ।

HTTP ଲାଇବ୍ରେରୀ ଯାହାର ବାଇଟ୍ ଲମ୍ବା ଜାଣେ ଏପରି ସ୍ଥିର ଫାଇଲ ଅଜଣା ପରିମାଣର ଡାଟା ଉତ୍ପାଦନ କରୁଥିବା ଜେନେରେଟରଠାରୁ ଅଲଗା। ଦୁଇ ଉତ୍ସ ପାଇଁ ଲାଇବ୍ରେରୀ ଦ୍ୱାରା ସମର୍ଥିତ ବଡି ଇଣ୍ଟରଫେସ ବ୍ୟବହାର କରନ୍ତୁ। କେବଳ ଲମ୍ବା ଦେବା ପାଇଁ ସମଗ୍ର ଫାଇଲକୁ ଏକ ଷ୍ଟ୍ରିଙ୍ଗରେ ଯୋଡ଼ିବା ଆବଶ୍ୟକ ନାହିଁ।

HTTP/1.1 ପାଇଁ, ପ୍ରୋଟୋକଲର ନିୟମ ଅନୁସାରେ ପ୍ରକୃତରେ ପଠାଯାଇଥିବା ଫ୍ରେମିଂ ଯାଞ୍ଚ କରନ୍ତୁ: Content-Length କିମ୍ବା chunked ସ୍ଥାନାନ୍ତର କୋଡିଂ। Chunked କୋଡିଂ ଫାଇଲର ବିଷୟବସ୍ତୁ ବାହାରେ ଆକାର ଚିହ୍ନ ଯୋଡ଼େ। ପରସ୍ପର ବିରୋଧୀ ଫ୍ରେମିଂ ଫିଲ୍ଡ ଏକତ୍ର କରନ୍ତୁ ନାହିଁ ଏବଂ ପ୍ରକ୍ସିକୁ ଅପଲୋଡ଼ ଗ୍ରହଣ କରିବାକୁ ମନାଇବା ପାଇଁ ଲମ୍ବା ଅନୁମାନ କରନ୍ତୁ ନାହିଁ।

ଯଦି ପ୍ରକ୍ସି ମାଧ୍ୟମରେ ଅପଲୋଡ଼ ବିଫଳ ହୁଏ, HTTP ସଂସ୍କରଣ, ବଡିର ଉତ୍ସ ଏବଂ ପ୍ରଥମ ଅସ୍ୱୀକୃତି ଲିପିବଦ୍ଧ କରନ୍ତୁ। 411 ପ୍ରତିକ୍ରିୟା ବଡି ମଝିରେ ବନ୍ଦ ହେଉଥିବା ସଂଯୋଗଠାରୁ ଅଲଗା ଅନୁସନ୍ଧାନ ସୂଚାଏ। ଯଦି ଏହାର ବିପରୀତ ପ୍ରମାଣୀକରଣ ପୁନଃପ୍ରୟାସ ବିଫଳ ହୁଏ, ଯାଞ୍ଚ କରନ୍ତୁ ଅପଲୋଡ଼ ବଡି ପୁନଃ ଚଲାଯାଇପାରିବ କି ନାହିଁ। ଆପ୍ଲିକେସନର ରିଡ-ବଫର ଆକାର ବଦଳାଇଲେ ଅନୁରୋଧର ଫ୍ରେମିଂ ପୂର୍ବପରି ରହିପାରେ।

ସେହି ପର୍ଯ୍ୟବେକ୍ଷଣ ପାଇଁ ପଥ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। ସାଧାରଣ ପାଠ୍ୟ ଅଗ୍ରେଷଣ ଅପଲୋଡ଼ର HTTP ଫ୍ରେମିଂକୁ ପ୍ରକ୍ସି ସାମ୍ନାରେ ଖୋଲିଦିଏ; ସାଧାରଣ ଏଣ୍ଡ-ଟୁ-ଏଣ୍ଡ HTTPS ଏହାକୁ ସୁରଙ୍ଗ ଭିତରେ ରଖେ। HTTP/2 ନିଜସ୍ୱ ଫ୍ରେମିଂ ବ୍ୟବହାର କରେ। ତେଣୁ ଐତିହାସିକ Squid ସୀମା କିଛି ପୁରୁଣା ବିଫଳତା ବ୍ୟାଖ୍ୟା କରେ, ଆଜିର ପ୍ରତ୍ୟେକ ପ୍ରକ୍ସି ସ୍ଟ୍ରିମ ଅପଲୋଡ଼କୁ ଅସ୍ୱୀକାର କରେ ବୋଲି ନିୟମ ନୁହେଁ।