.NET HttpClient हेडर और बॉडी के लिए एक ही CancellationToken का उपयोग करें
अनुरोध के CancellationToken को HttpClient प्रतिक्रिया तैयारी और बॉडी पढ़ने, दोनों में ले जाएँ, न कि केवल कॉलर के इंतज़ार को मापें।
HTTP अनुरोध के जारी रहने पर स्टॉपवॉच इंतज़ार करना बंद कर सकती है। जब प्रॉक्सी के ज़रिए किया गया प्रयास एक निर्धारित बजट रखता हो, तो रद्दीकरण स्वयं ऑपरेशन को दें।
मौजूदा प्रॉक्सी-कॉन्फ़िगर किए गए HttpClient वाले आधुनिक .NET अनुप्रयोग के लिए:
using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(5));
using var response = await client.GetAsync(
targetUrl,
HttpCompletionOption.ResponseHeadersRead,
budget.Token);
response.EnsureSuccessStatusCode();
string body = await response.Content.ReadAsStringAsync(budget.Token);
वही बजट तैयारी से पहले शुरू होता है और बॉडी पढ़े जाने के दौरान सक्रिय रहता है। ResponseHeadersRead हेडर के बाद नियंत्रण लौटाता है, इसलिए HttpClient का अपना पूर्णता टाइमआउट अपने आप बाद के बॉडी-पठन बजट को परिभाषित नहीं करता।
रद्दीकरण को HTTP स्थिति और परिवहन त्रुटियों से अलग रखें। OperationCanceledException दिए गए टोकन से या किसी अन्य कॉन्फ़िगर किए गए टाइमआउट से आ सकता है; हर विफलता को मृत प्रॉक्सी बताने के बजाय लागू रद्दीकरण स्रोत की जाँच करें।
इस प्रॉक्सी मार्ग का स्वामी क्लाइंट पुनः उपयोग करें। किसी प्रयास को रद्द करने का अर्थ यह नहीं है कि हर आगामी अनुरोध के लिए पूरा कनेक्शन पूल फिर से बनाया जाए।
उदाहरण एक सीमित प्रतिक्रिया बॉडी को बफ़र करता है। स्ट्रीमिंग डाउनलोड को टोकन अपने स्ट्रीम-कॉपी लूप से गुज़ारना चाहिए और हर निकास मार्ग पर प्रतिक्रिया जारी करनी चाहिए।
रद्दीकरण किसी ऑपरेशन की नीति व्यक्त करता है, हर अंतर्निहित प्लेटफ़ॉर्म क्रिया के लिए सटीक वास्तविक-समय का वादा नहीं। इसे Task.IsCompleted पर अनंत पोलिंग लूप से बदलने से बचें।