प्रोक्सी चेकरहरूमा विश्वव्यापी urllib opener परिवर्तनबाट बच्नुहोस्
urllib प्रोक्सी जाँचहरूलाई तिनीहरूको आफ्नै opener मा राख्नुहोस्, सम्पूर्ण प्रक्रियाको राउटिङ र टाइमआउट पूर्वनिर्धारित बदल्नुको सट्टा।
from urllib.request import ProxyHandler, build_opener
def make_proxy_opener(proxy_uri):
return build_opener(ProxyHandler({
"http": proxy_uri,
"https": proxy_uri,
}))
opener = make_proxy_opener("http://proxy.example.net:8080")
# Use opener.open(destination, timeout=10) for this route.जब मार्ग जाँचको हुन्छ तब यो opener को आफ्नै open विधि कल गर्नुहोस्। उदाहरणको HTTP एन्डपोइन्ट तपाईंको सेवा वा सार्वजनिक जाँचका लागि HTTP प्रोक्सी सूचीबाट आउन सक्छ। यो अंशले स्वामित्व देखाउँछ; यसले पूर्ण प्रमाणीकरण वा स्वास्थ्य नीति परिभाषित गर्दैन। खाता-विशिष्ट कुनै पनि handler त्यही इच्छित क्लाइन्टमा जोडिएको राख्नुहोस्।
urllib.request.install_opener() प्रक्रिया-व्यापी पूर्वनिर्धारित बदल्छ जुन पछिका मोड्युल-स्तर urlopen() कलहरूले प्रयोग गर्छन्। त्यसैले प्रोक्सीहरूमा घुम्ने चेकरले असम्बन्धित अनुरोधहरूलाई आफ्नो अन्तिम एन्डपोइन्टमा छोड्न सक्छ। अस्थायी रूपमा स्थापना गरी सफाईमा पुनर्स्थापना गर्दा पनि साझा परिवर्तनका क्रममा समवर्ती अनुरोधहरू चल्न सक्छन्।
socket.setdefaulttimeout() त्यसैगरी पछि सिर्जना हुने socket का पूर्वनिर्धारित बदल्छ। जब केवल जाँचले मात्र यो प्राप्त गर्नुपर्छ तब सञ्चालन-स्तरको टाइमआउट प्रयोग गर्नुहोस्।
जाँचका प्रतिक्रियाहरू बन्द गर्नुहोस् र परिणामहरू विशिष्ट राख्नुहोस्: HTTP त्रुटि प्रतिक्रिया स्वतः मृत प्रोक्सी श्रोता होइन। यदि async सेवामा synchronous urllib जाँच प्रयोग गरिन्छ भने, अवरोध गर्ने काम उपयुक्त worker मा सार्नुहोस्; त्यो कार्यान्वयन निर्णयले विश्वव्यापी opener परिवर्तनलाई पृथक बनाउँदैन।
जाँचले अर्को नेटवर्क नीति पछाडि नछोडी आफ्नो अवलोकन फर्काउनुपर्छ। यसको आफ्नै क्लाइन्ट वस्तु र सीमित सञ्चालनले त्यो सीमा स्पष्ट बनाउँछ।