प्रॉक्सी प्रमाणीकरणाचे पुनः प्रयत्न आणि पुन्हा न करता येणारे अपलोड बॉडी

GET प्रॉक्सीद्वारे प्रमाणीकृत होऊ शकतो, तर POST किंवा PUT पुन्हा न करता येणारे बॉडी किंवा रिवाइंड त्रुटीने अयशस्वी होते. खाते बरोबर असू शकते: क्लायंटने अपलोड वापरल्यानंतरही प्रमाणीकरणाच्या देवाणघेवाणीसाठी आणखी एक विनंती लागू शकते.

libcurl बहु-टप्पा प्रमाणीकरणासह वापरांसाठी शोध कॉलबॅकचे दस्तऐवजीकरण करते. Jersey कनेक्टरच्या वर्तनावर अवलंबून बफर्ड आणि विभाजित एंटिटी-प्रोसेसिंग मोड देते. एक Jersey 2 Apache कनेक्टरचे उदाहरण बफर्ड सेटिंग दाखवते. यापैकी कोणीही अमर्यादित इन-मेमरी अपलोड योग्य करत नाही.

जी पद्धत आणि बॉडी स्रोत अयशस्वी होतात ते पुनरुत्पादित करा. तयारीच्या GET मध्ये पुन्हा चालवण्यासाठी अपलोड नाही, आणि नंतरचे अपलोड त्याचे कनेक्शन किंवा प्रमाणीकरण स्थिती सामायिक करते हे ते सिद्ध करत नाही. नवीन गंतव्य, क्लायंट ऑब्जेक्ट किंवा कनेक्शन धोरण ते बदलू शकते. फाइल-आधारित बॉडी आणि थेट स्ट्रीम देखील वेगळे असतात, जरी त्यांचा नमुना मजकूर सारखाच असला तरी.

आपण बफर करत असल्यास, त्याची आकारमर्यादा, संग्रहण स्थान आणि आयुष्य निश्चित करा. एकाच वेळी होणारे अपलोड खर्च अनेक पटीने वाढवतात, आणि संवेदनशील डेटा बफर जिथे ठेवला जातो तिथेच राहतो.

ज्ञात सुसंगत प्रॉक्सीकडे पूर्व-प्रमाणीकरण एका सुरुवातीच्या आव्हानाला टाळू शकते. परंतु आणखी एक प्रयत्न लागू शकणारी प्रत्येक पुढील प्रमाणीकरण फेरी, रीडायरेक्ट किंवा बंद कनेक्शन ते वगळू शकत नाही.

प्रॉक्सीचा प्रतिसाद, बॉडी वापराचा बिंदू आणि रिप्ले त्रुटी एकत्र ठेवा. नंतर प्रोटोकॉल रिप्ले आणि अनिश्चित ॲप्लिकेशन निकाल वेगळे करा: प्रतिसाद हरवण्यापूर्वी सबमिशन प्रक्रिया झालेली असू शकते. पुन्हा पाठवण्यापूर्वी गंतव्याचे idempotency नियम पाळा.