प्रोक्सी प्रमाणीकरणका पुनः प्रयास र दोहोर्याउन नसकिने अपलोड बडी

GET ले प्रोक्सीमार्फत प्रमाणीकरण गर्न सक्छ जबकि POST वा PUT दोहोर्याउन नसकिने बडी वा रिवाइन्ड त्रुटिले असफल हुन्छ। खाता सही हुन सक्छ: ग्राहकले अपलोड उपभोग गरिसकेपछि पनि प्रमाणीकरणको आदानप्रदानलाई अर्को अनुरोध चाहिन सक्छ।

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

असफल हुने विधि र बडी स्रोत पुनरुत्पादन गर्नुहोस्। तयारीको GET सँग दोहोर्याउन कुनै अपलोड हुँदैन, र यसले पछिको अपलोडले यसको जडान वा प्रमाणीकरण स्थिति साझा गर्छ भनी प्रमाणित गर्दैन। नयाँ गन्तव्य, ग्राहक वस्तु वा जडान नीतिले यो बदल्न सक्छ। फाइल-आधारित बडी र प्रत्यक्ष स्ट्रिम पनि फरक हुन्छन्, तिनीहरूको नमुना पाठ एउटै भए पनि।

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

परिचित अनुकूल प्रोक्सीमा पूर्व-प्रमाणीकरण ले एउटा प्रारम्भिक चुनौतीबाट बच्न सक्छ। तर अर्को प्रयास आवश्यक पर्न सक्ने हरेक पछिको प्रमाणीकरण चरण, रिडिरेक्ट वा बन्द जडानलाई यसले बहिष्कृत गर्न सक्दैन।

प्रोक्सीको प्रतिक्रिया, बडी उपभोगको बिन्दु र रिप्ले त्रुटि सँगै राख्नुहोस्। त्यसपछि प्रोटोकल रिप्लेलाई अनिश्चित अनुप्रयोग परिणामबाट छुट्याउनुहोस्: प्रतिक्रिया हराउनुअघि पेस गरिएको कुरा प्रशोधन भइसकेको हुन सक्छ। फेरि पठाउनुअघि गन्तव्यको idempotency नियमहरू पालना गर्नुहोस्।