प्रॉक्सी प्रमाणीकरण के पुनः प्रयास और दोबारा न किए जा सकने वाले अपलोड बॉडी

एक GET प्रॉक्सी के माध्यम से प्रमाणीकृत हो सकता है, जबकि POST या PUT गैर-पुनरावर्तनीय बॉडी या रिवाइंड त्रुटि के साथ विफल हो जाता है। खाता सही हो सकता है: क्लाइंट द्वारा अपलोड का उपभोग कर लेने के बाद भी प्रमाणीकरण के आदान-प्रदान को एक और अनुरोध की आवश्यकता हो सकती है।

libcurl बहु-चरणीय प्रमाणीकरण सहित उपयोगों के लिए खोज कॉलबैक का दस्तावेज़ीकरण करता है। Jersey कनेक्टर के व्यवहार के अधीन बफ़र्ड और खंडित एंटिटी-प्रोसेसिंग मोड प्रदान करता है। एक Jersey 2 Apache कनेक्टर का उदाहरण बफ़र्ड सेटिंग दिखाता है। इनमें से कोई भी असीमित इन-मेमोरी अपलोड को उपयुक्त नहीं बनाता।

जो विधि और बॉडी स्रोत विफल होते हैं, उन्हें पुनरुत्पादित करें। प्रारंभिक GET के पास दोबारा चलाने के लिए कोई अपलोड नहीं है, और यह सिद्ध नहीं करता कि बाद का अपलोड उसका कनेक्शन या प्रमाणीकरण स्थिति साझा करता है। नया गंतव्य, क्लाइंट ऑब्जेक्ट या कनेक्शन नीति इसे बदल सकते हैं। फ़ाइल-आधारित बॉडी और लाइव स्ट्रीम भी भिन्न होते हैं, भले ही उनका नमूना पाठ एक ही हो।

यदि आप बफ़र करते हैं, तो उसकी आकार सीमा, संग्रहण स्थान और जीवनकाल परिभाषित करें। एक साथ किए गए अपलोड लागत को कई गुना बढ़ा देते हैं, और संवेदनशील डेटा वहीं रहता है जहाँ बफ़र रखा जाता है।

ज्ञात संगत प्रॉक्सी के लिए पूर्व-प्रमाणीकरण एक प्रारंभिक चुनौती से बच सकता है। यह हर बाद के प्रमाणीकरण दौर, रीडायरेक्ट या बंद कनेक्शन को बाहर नहीं कर सकता जिसके लिए एक और प्रयास की आवश्यकता हो सकती है।

प्रॉक्सी की प्रतिक्रिया, बॉडी के उपभोग का बिंदु और रिप्ले त्रुटि को साथ रखें। फिर प्रोटोकॉल रिप्ले को अनिश्चित एप्लिकेशन परिणाम से अलग करें: हो सकता है कि सबमिशन उसका प्रतिक्रिया खोने से पहले संसाधित हो गया हो। दोबारा भेजने से पहले गंतव्य के idempotency नियमों का पालन करें।