ପ୍ରକ୍ସି ପ୍ରମାଣୀକରଣର ପୁନଃ ପ୍ରୟାସ ଏବଂ ପୁନରାବୃତ୍ତି ଅସମ୍ଭବ ଅପଲୋଡ୍ ବଡି
ପ୍ରମାଣୀକରଣର ପୁନଃ ପ୍ରୟାସ କିପରି ଏକ-ଥରିଆ ଅପଲୋଡ୍ ପ୍ରବାହକୁ ପ୍ରକାଶ କରିପାରେ ତାହା ବୁଝନ୍ତୁ, ଏବଂ ସୀମିତ ବଫରିଂ କିମ୍ବା ପୁନରାବୃତ୍ତି ଯୋଗ୍ୟ ବିଷୟବସ୍ତୁ ସଚେତନ ଭାବରେ ବାଛନ୍ତୁ।
GET ପ୍ରକ୍ସି ମାଧ୍ୟମରେ ପ୍ରମାଣୀକରଣ କରିପାରେ, ମାତ୍ର POST କିମ୍ବା PUT ପୁନରାବୃତ୍ତି ଅସମ୍ଭବ ବଡି କିମ୍ବା ରିୱାଇଣ୍ଡ ତ୍ରୁଟି ସହିତ ବିଫଳ ହୁଏ। ଖାତା ସଠିକ୍ ହୋଇପାରେ: ଗ୍ରାହକ ଅପଲୋଡ୍ ବ୍ୟବହାର କରିସାରିବା ପରେ ମଧ୍ୟ ପ୍ରମାଣୀକରଣ ବିନିମୟକୁ ଆଉ ଏକ ଅନୁରୋଧ ଆବଶ୍ୟକ ହୋଇପାରେ।
| ବଡିର ଉତ୍ସ | ପୁନଃ ଚଲାଇବାର ବିକଳ୍ପ |
|---|---|
| ଛୋଟ ସୀମିତ ବଡି | ଏକ ସୀମିତ ବଫର ଏହାର ବାଇଟ୍ ରଖିପାରେ। |
| ଖୋଜିବା ଯୋଗ୍ୟ ଫାଇଲ୍ | ଗ୍ରାହକ ସମର୍ଥିତ ରିୱାଇଣ୍ଡ ଇଣ୍ଟରଫେସ୍ ଏହାକୁ ପୁନରାବୃତ୍ତି ଯୋଗ୍ୟ କରିପାରେ। |
| ଜେନେରେଟର, ପାଇପ୍ କିମ୍ବା ଲାଇଭ୍ ଉତ୍ପାଦକ | ଏକ-ଥରିଆ ଉତ୍ସ ପାଇଁ ଅନ୍ୟ ଡିଜାଇନ୍ ଆବଶ୍ୟକ ହୋଇପାରେ। |
libcurl ବହୁ-ପର୍ଯ୍ୟାୟ ପ୍ରମାଣୀକରଣ ସହିତ ବ୍ୟବହାର ପାଇଁ ସନ୍ଧାନ କଲବ୍ୟାକ୍ ଦସ୍ତାବିଜ୍ କରେ। Jersey କନେକ୍ଟରର ଆଚରଣ ଅଧୀନରେ ବଫର୍ଡ ଏବଂ ଖଣ୍ଡିତ ଏଣ୍ଟିଟି-ପ୍ରୋସେସିଂ ମୋଡ୍ ପ୍ରଦାନ କରେ। ଏକ Jersey 2 Apache କନେକ୍ଟରର ଉଦାହରଣ ବଫର୍ଡ ସେଟିଂ ଦେଖାଏ। ଏଥିମଧ୍ୟରୁ କୌଣସିଟି ଅସୀମିତ ଇନ୍-ମେମୋରୀ ଅପଲୋଡ୍କୁ ଉପଯୁକ୍ତ କରେ ନାହିଁ।
ଯେଉଁ ପଦ୍ଧତି ଓ ବଡି ଉତ୍ସ ବିଫଳ ହୁଏ ତାହା ପୁନରୁତ୍ପାଦନ କରନ୍ତୁ। ପ୍ରସ୍ତୁତି GET ରେ ପୁନଃ ଚଲାଇବା ପାଇଁ କୌଣସି ଅପଲୋଡ୍ ନାହିଁ, ଏବଂ ଏହା ପ୍ରମାଣ କରେ ନାହିଁ ଯେ ପରବର୍ତ୍ତୀ ଅପଲୋଡ୍ ଏହାର ସଂଯୋଗ କିମ୍ବା ପ୍ରମାଣୀକରଣ ସ୍ଥିତି ଅଂଶୀଦାର କରେ। ନୂତନ ଗନ୍ତବ୍ୟ, ଗ୍ରାହକ ବସ୍ତୁ କିମ୍ବା ସଂଯୋଗ ନୀତି ତାହା ବଦଳାଇପାରେ। ଫାଇଲ୍-ଆଧାରିତ ବଡି ଏବଂ ଲାଇଭ୍ ଷ୍ଟ୍ରିମ୍ ମଧ୍ୟ ଭିନ୍ନ, ଯଦିଓ ସେମାନଙ୍କର ନମୁନା ପାଠ ସମାନ।
ଯଦି ଆପଣ ବଫର୍ କରନ୍ତି, ଏହାର ଆକାର ସୀମା, ସଂରକ୍ଷଣ ସ୍ଥାନ ଏବଂ ଆୟୁ ନିର୍ଦ୍ଧାରଣ କରନ୍ତୁ। ଏକକାଳୀନ ଅପଲୋଡ୍ ଖର୍ଚ୍ଚକୁ ଗୁଣିତ କରେ, ଏବଂ ସମ୍ବେଦନଶୀଳ ତଥ୍ୟ ଯେଉଁଠି ବଫର ରଖାଯାଏ ସେଠାରେ ରହେ।
ଜଣା ସୁସଙ୍ଗତ ପ୍ରକ୍ସି ପାଇଁ ପୂର୍ବ-ପ୍ରମାଣୀକରଣ ଏକ ପ୍ରାରମ୍ଭିକ ଚ୍ୟାଲେଞ୍ଜ ଏଡ଼ାଇପାରେ। କିନ୍ତୁ ଆଉ ଏକ ପ୍ରୟାସ ଆବଶ୍ୟକ କରିପାରୁଥିବା ପରବର୍ତ୍ତୀ ପ୍ରତ୍ୟେକ ପ୍ରମାଣୀକରଣ ରାଉଣ୍ଡ, ରିଡାଇରେକ୍ଟ କିମ୍ବା ବନ୍ଦ ସଂଯୋଗକୁ ଏହା ବାଦ୍ ଦେଇପାରିବ ନାହିଁ।
ପ୍ରକ୍ସିର ପ୍ରତିକ୍ରିୟା, ବଡି ବ୍ୟବହାରର ବିନ୍ଦୁ ଏବଂ ରିପ୍ଲେ ତ୍ରୁଟି ଏକାଠି ରଖନ୍ତୁ। ତାପରେ ପ୍ରୋଟୋକଲ୍ ରିପ୍ଲେକୁ ଅନିଶ୍ଚିତ ଆପ୍ଲିକେସନ୍ ଫଳାଫଳରୁ ଅଲଗା କରନ୍ତୁ: ପ୍ରତିକ୍ରିୟା ହଜିବା ପୂର୍ବରୁ ସବମିଶନ୍ ପ୍ରକ୍ରିୟା ହୋଇସାରିଥାଇପାରେ। ପୁନଃ ପଠାଇବା ପୂର୍ବରୁ ଗନ୍ତବ୍ୟର idempotency ନିୟମ ଅନୁସରଣ କରନ୍ତୁ।