बाइनरी फ़ाइल को HTTP क्लाइंट तक बाइट्स के रूप में पहुँचना चाहिए। इसे टेक्स्ट रीडर से पढ़कर परिणामी स्ट्रिंग को ASCII के रूप में फिर से एन्कोड करने से प्रॉक्सी को कुछ मिलने से पहले ही मान बदल सकते हैं। छोटा टेक्स्ट नमूना काम करना उस रास्ते को किसी छवि, संग्रह या दस्तावेज़ के लिए सुरक्षित नहीं बनाता।

मौजूदा .NET अपलोड पथ में, उस रूपांतरण को बाइनरी बॉडी स्रोत से बदलें:

using var file = File.OpenRead(path);
using var content = new StreamContent(file);

सामग्री को एप्लिकेशन के कॉन्फ़िगर किए गए HTTP अपलोड से गुज़ारें; अंश बॉडी स्रोत स्थापित करता है, जबकि मौजूदा क्लाइंट अभी भी विधि, गंतव्य, प्रॉक्सी और जीवनकाल प्रबंधन का मालिक है।

पुरानी स्ट्रिंग की वर्ण संख्या से गणना किया गया कोई भी Content-Length हटा दें। यह फ़ील्ड ऑक्टेट मापता है। वर्ण संख्या को भिन्न एन्कोडिंग वाले बफ़र के साथ जोड़ने के बजाय HTTP लाइब्रेरी को बॉडी प्रस्तुति से फ़्रेमिंग बनाने दें।

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

स्थानांतरित फ़ाइल की तुलना किसी विश्वसनीय अपेक्षित मान से करें। HTTP सफलता पुष्टि करती है कि उस परत पर अपलोड क्रिया पूरी हुई; यह नहीं दिखा सकती कि पिछले टेक्स्ट रूपांतरण ने मूल बाइट्स सुरक्षित रखे थे।

संबंधित लेख