Requests: टीएलएस एसएनआई सपोर्ट

Stdlib के ssl मॉड्यूल के शीर्ष पर Python 2.x में पॉसिबल नहीं है।

मुड़ गया है, है ना? शायद pyopenssl या किसी अन्य ssl मॉड्यूल पर निर्भर होने का समय?

urllib3 के लिए Py32+ के लिए SNI समर्थन जोड़ने के लिए एक पुल अनुरोध है, लेकिन अभी भी परीक्षण कवरेज की आवश्यकता है। https://github.com/shazow/urllib3/pull/89

shzow: सूचक के लिए धन्यवाद। मैं दुर्भाग्य से ट्विस्टेड/फ्लास्क का उपयोग कर रहा हूं, जिसका अर्थ है कि मैं 2.7 पर अटक गया हूं। ऐसा लगता है कि ऐसा कुछ ऐसा कर सकता है, लेकिन मैंने उदाहरण नहीं देखे हैं, और इसे करने के लिए इसे pyopenssl + मुड़ डिकोडिंग की आवश्यकता होगी। मैं इसे दूर करने के लिए विशेषज्ञ नहीं हूं। इस बिंदु पर, बस कुछ कमांड लाइन उपयोगिता जैसे wget को लपेटने की सोच रहा है ... :(

PyOpenSSL इसे 2.x पर करने में सक्षम होना चाहिए। तो आशा है।

मैं इसे pyopenssl के साथ काम कर सकता था। लेकिन मुझे अभी भी इसे सही ढंग से मुड़ने में मुश्किल हो रही है। http://pbin.be/show/719/ -- प्रकार के कार्य। लेकिन फिर किसी को उपयोगी होने के लिए उस पर एक एपीआई बनाना होगा। मैं अभी भी यह नहीं समझ सकता कि एजेंट को सही संदर्भ कैसे दिया जाए।

लुकासा: क्या यह हल हो गया था?

नहीं. हमें shazow/urllib3#89 पर ब्लॉक कर दिया गया है.

विलय होना। जारी रखो। :)

ध्यान दें कि यह अभी के लिए केवल Py32+ पर समर्थित है। हालांकि शुरू करने के लिए पर्याप्त होना चाहिए।

एक और उचित चेतावनी: Py32 पर कुछ परीक्षण अभी urllib3 मास्टर पर विफल हो रहे हैं। इसे हल करने में कुछ मदद की बहुत सराहना की जाएगी (और इस कार्यक्षमता को प्रभावित कर सकती है): https://github.com/shazow/urllib3/issues/128

मेरे लिए py26, py27, py32, py33 पर आर्चलिनक्स x64 पर काम करता है

आह मुझे योग्य होना चाहिए था कि यह ओएसएक्स पर है। बदमाश OSX।

t-8ch: क्या आपके लिए py26/27/32 और 33 पर sni परीक्षण गुजर रहे हैं?

एसएनआई परीक्षण py2 पर भी नहीं चलते हैं, लेकिन py32 और py33 पर यह काम करता है।
py32 से पहले मानक पुस्तकालय के एसएसएल मॉड्यूल के साथ एसएनआई करने का कोई तरीका नहीं है।

@shazow : संभवतः आपको urllib3 को PyOpenSSL पर निर्भर बनाने में कोई दिलचस्पी नहीं है?

मुझे एक अलग पुस्तकालय के लिए खुशी होगी जो एसएसएल को PyOpenSSL समर्थन के माध्यम से urllib3 में जोड़ता है।

ऐसा लगता है कि @ t-8ch urllib3 पर काम के साथ इसे पार्क से बाहर कर रहा है। मैं उसे बताऊंगा कि इसे कब बंद किया जा सकता है।

urllib3 में कुछ वैकल्पिक निर्भरताओं के साथ पाइथन 2 के साथ एसएनआई के लिए वैकल्पिक समर्थन है। (देखें urllib3#156 )।

मुझे विश्वास है कि इसका उपयोग करके काम करना चाहिए:

from requests.packages.urllib3.contrib import pyopenssl
pyopenssl.inject_into_urllib3

इसे packages में setup.py जोड़ने के बाद

requests.packages.urllib3.contrib

ध्यान दें कि contrib पैकेज डिफ़ॉल्ट रूप से आयात नहीं किया जाता है।

अनुरोधों में SNI को सक्षम करने के लिए मूल रूप से दो विकल्प हैं:

• एसएनआई को मैन्युअल रूप से सक्षम करने के लिए फ़ंक्शन बनाएं जो मूल रूप से उपरोक्त कोड चलाता है। (नकारात्मक पक्ष यह है कि उपयोगकर्ताओं को एसएनआई समर्थन को स्पष्ट रूप से सक्षम करने की आवश्यकता होगी)।
• पूर्व-आवश्यकताएं आयात करने का प्रयास करें। यदि वे मौजूद हैं, तो SNI सक्षम करें, अन्यथा नहीं।

मुझे दोनों विकल्पों में से किसी को भी लागू करने में कोई समस्या नहीं है, हालांकि मैं यह जानना पसंद करूंगा कि अनुरोधों के लिए कौन सा पसंद किया जाएगा। मैं व्यक्तिगत रूप से दूसरे विकल्प के लिए वोट करता हूं।

बीटीडब्लू: क्या हम इस मुद्दे को फिर से खोल सकते हैं, अब हमारे पास urllib3 से समर्थन है?

मैं वास्तव में पूर्व को पसंद करता हूं क्योंकि जिन लोगों को इसकी आवश्यकता होती है, वे जानते हैं कि उन्हें इसकी आवश्यकता होगी और वे इतने कम हैं कि इससे बहुत अधिक शिकायतें नहीं होंगी। हालांकि, अगर हम मौजूदा एपीआई के अनुरूप होने जा रहे हैं, तो बाद वाला इसे लागू करने का तरीका होगा। वर्तमान में, urllib3 (और अनुरोध) ssl मॉड्यूल के बिना HTTPS अनुरोध भेजने के लिए API प्रदान करेगा लेकिन उस स्थिति में विफल हो जाएगा जहां ssl मॉड्यूल उपलब्ध नहीं है। दूसरे शब्दों में, एपीआई है और आप इसका उपयोग कर सकते हैं लेकिन यह काम नहीं करेगा और यह एक अपवाद द्वारा इंगित किया गया है।

इसे फिर से खोलने के लिए, यह @kennethreitz तक है। बेशक (इस सब के साथ) मुद्दा यह है कि हम वर्तमान में एक फीचर फ्रीज (#1165, #1168) के तहत हैं, इसलिए मुझे यकीन नहीं है कि काम करने लायक भी है क्योंकि इसे स्वीकार नहीं किया जा सकता है।

मुझे थोड़ा स्पष्ट होने दें: दूसरे विकल्प से मेरा मतलब यह था कि "वैकल्पिक डीपीएस उपलब्ध होने पर एसएनआई का उपयोग करने का प्रयास करें, लेकिन फिर भी एसएसएल का उपयोग करें क्योंकि हमारे पास हमेशा ऐसा होता है।" यह अब तक मौजूद कुछ भी नहीं तोड़ना चाहिए।

मुद्दे को फिर से खोलने (या नहीं) के लिए, आईएमएचओ, इस मुद्दे को हल्के में नहीं लिया जाना चाहिए। कई परिदृश्यों के लिए एसएनआई समर्थन के बिना अनुरोध बेकार हो सकते हैं। विशेष रूप से, SNI के बिना एकल IPv4 होस्ट पर एकाधिक डोमेन असंभव हो जाते हैं। और अतिरिक्त IPv4 पते कई उपयोगकर्ताओं के लिए सवालों के घेरे में हैं (उनकी लागत के कारण)।

किसी भी मामले में, यह आधा फीचर है, आधा बग है, हालांकि मैं इस मुद्दे को फिर से खोलने के संबंध में @kennethreitz के जवाब का इंतजार

ह्यूगो: मैंने अभी-अभी pip install -U अनुरोध किया है, और जब मैं contrib आयात नहीं कर सकता।
मुझसे इसका समाधान किस प्रकार होगा? (आयातक: योगदान नाम का कोई मॉड्यूल नहीं)।

शुक्र, 3 मई, 2013 को दोपहर 1:12 बजे, ह्यूगो ओस्वाल्डो बर्रेरा <
सूचनाएं@github.com> ने लिखा:

urllib3 में अजगर 2 के साथ SNI के लिए वैकल्पिक समर्थन है, हालांकि कुछ के साथ
वैकल्पिक निर्भरता। (देखें urllib3#156https://github.com/shazow/urllib3/pull/156
)

मुझे विश्वास है कि इसका उपयोग करके काम करना चाहिए:

request.packages.urllib3.contrib से आयात pyopenssl
pyopenssl.inject_into_urllib3

ध्यान दें कि डिफ़ॉल्ट रूप से योगदान पैकेज आयात नहीं किया जाता है।

अनुरोधों में SNI को सक्षम करने के लिए मूल रूप से दो विकल्प हैं:

• एसएनआई को मैन्युअल रूप से सक्षम करने के लिए फ़ंक्शन बनाएं जो मूल रूप से उपरोक्त चलाता है
  कोड। (नकारात्मक पक्ष यह है कि उपयोगकर्ताओं को एसएनआई को स्पष्ट रूप से सक्षम करने की आवश्यकता होगी
  सहयोग)।
• पूर्व-आवश्यकताएं आयात करने का प्रयास करें। यदि वे मौजूद हैं, तो SNI सक्षम करें, अन्यथा
  नहीं।

मुझे दोनों विकल्पों में से किसी को भी लागू करने में कोई समस्या नहीं है, हालांकि मैं पसंद करूंगा
यह जानने के लिए कि अनुरोधों के लिए कौन सा पसंदीदा होगा। मैं व्यक्तिगत रूप से वोट करता हूं
दूसरा विकल्प।

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/kennethreitz/requests/issues/749#issuecomment -17406518
.

अनुरोध के setup.py में वह पैकेज शामिल नहीं है (वह स्रोत है, लेकिन इसे इंस्टॉल/पैकेजिंग करते समय बाहर रखा गया है), इसलिए यह स्थापित नहीं है, इसलिए मैंने उल्लेख किया है:

इसे packages in setup.py जोड़ने के बाद
request.packages.urllib3.contrib

आपको मूल रूप से स्रोत से इंस्टॉल करना होगा।
यदि आप रुचि रखते हैं, तो मेरा पुल अनुरोध देखें, यह काम केवल दो पंक्तियों में करना है। :)

"यदि वैकल्पिक डिपो उपलब्ध हैं तो एसएनआई का उपयोग करने का प्रयास करें, लेकिन फिर भी एसएसएल का उपयोग करें क्योंकि हमारे पास हमेशा ऐसा होता है।"

हालांकि एसएसएल हमेशा नहीं होता है। वह मेरी बात थी। वर्तमान में हम कोशिश करते हैं और इसका इस्तेमाल करते हैं लेकिन अगर हमारे पास यह नहीं है और कोई उपयोगकर्ता https अनुरोध करने का प्रयास करता है तो वह कठिन और तेज़ विफल हो जाता है। जिस तरह से आपने इसका वर्णन किया था, मैं इस धारणा के तहत था कि एसएनआई को उपयोगकर्ता को urllib3 पर कुछ अतिरिक्त धारणा पारित करने की आवश्यकता होगी और आप इसके लिए केवल सेट-अप पर ध्यान केंद्रित कर रहे थे। अगर सिर्फ #1347 जरूरी है तो मैं इसके पीछे 100% हूं।

यह वास्तव में अच्छा होगा यदि यह डिफ़ॉल्ट (एसएनआई समर्थन) और अनुरोध था
बिना किसी अतिरिक्त कोड या स्रोत से सेटअप के बस काम करता है। urllib3 के लिए इसके 2
कोड की पंक्तियाँ। क्यों न केवल इसे अनुरोधों में जोड़ें। क्या मैं दिन में सपना देख रहा हूँ? :)

शुक्र, 3 मई, 2013 को रात 10:43 बजे, इयान कॉर्डास्को नोटिफिकेशन @github.comलिखा:

"वैकल्पिक विवरण उपलब्ध होने पर एसएनआई का उपयोग करने का प्रयास करें, लेकिन फिर भी एसएसएल का उपयोग करें
हमारे पास हमेशा यह होता है कि वे नहीं हैं।"

हालांकि एसएसएल हमेशा नहीं होता है। वह मेरी बात थी। वर्तमान में हम कोशिश करते हैं और
इसका उपयोग करें, लेकिन यदि हमारे पास यह नहीं है और उपयोगकर्ता इसे बनाने की कोशिश करता है तो यह कठिन और तेज़ विफल हो जाता है
एक https अनुरोध। जिस तरह से आपने इसका वर्णन किया था, मैं उसके अधीन था
इंप्रेशन एसएनआई के लिए उपयोगकर्ता को urllib3 पर कुछ अतिरिक्त धारणाएं पारित करने की आवश्यकता होगी
और आप इसके लिए केवल सेट-अप पर ध्यान केंद्रित कर रहे थे। यदि वह सब आवश्यक है
है #1347 https://github.com/kennethreitz/requests/issues/1347 तो मैं हूं
इसके पीछे 100%।

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/kennethreitz/requests/issues/749#issuecomment -17426626
.

@pythonmobile एक शीर्ष स्पिन। यदि यह घूमना बंद नहीं करता है, तो आप सपना देख रहे हैं।

दूसरों के लिए एक टिप्पणी छोड़ना जो मेरे जैसे ही मुद्दे में भाग ले सकते हैं:
यदि आपको requests लाइब्रेरी का उपयोग करके सुरक्षित अनुरोध करने में समस्या हो रही है, विशेष रूप से Google ऐप इंजन पर होस्ट किए गए ऐप को हिट करने का प्रयास करते समय, ऐसा ऐसा क्यों हो सकता है। मैं जो त्रुटि देख रहा था वह था "ईओएफ प्रोटोकॉल के उल्लंघन में हुआ"। इसका निदान करने के लिए, s_client का उपयोग करके उसी होस्ट को हिट करने का प्रयास करें ( example.com को प्रश्न में होस्ट के साथ बदलें):

openssl s_client -connect example.com:443
openssl s_client -connect example.com:443 -servername example.com

यदि पहला आदेश "हैंडशेक विफलता" के साथ विफल हो जाता है और दूसरा सफल होता है, तो आप एसएनआई का उपयोग करने वाले सर्वर को हिट करने का प्रयास कर रहे हैं। वर्तमान सूत्र में इस स्थिति में requests काम करने के तरीके के बारे में कुछ अच्छी जानकारी है। मैंने जो किया वह ipython में from requests.packages.urllib3.contrib import pyopenssl चलाने का प्रयास था, और मैं किसी भी आयात त्रुटियों को स्थापित करने के लिए पाइप पर रहा। वाईएमएमवी।

@mshang संस्करण 1.2.3 यह आपके लिए पहले से ही करना चाहिए; क्या आप वाकई उस संस्करण को चला रहे हैं?

@hobarrera हाँ, मैं 1.2.3 चला रहा हूँ। requests.packages.urllib3.contrib वहाँ था, लेकिन उस आयात विवरण ने अभी भी आयात त्रुटियों का एक गुच्छा फेंक दिया। मुझे ndg-httpsclient इंस्टॉल करना पड़ा और मैं और क्या भूल गया।

सही। अनुरोध केवल आवश्यक मॉड्यूल आयात करने का प्रयास करता है, और यदि यह हार नहीं मानता है और अपने जीवन के साथ जारी रहता है। हालांकि, अनुरोधों के साथ एसएनआई का उपयोग करने के लिए आपको जो कुछ भी चाहिए, उसे दस्तावेज करना एक अच्छा विचार हो सकता है।

यह अनुरोध/पैकेज/urllib3/contrib/pyopenssl.py में निर्दिष्ट है :

• pyOpenSSL (0.13 के साथ परीक्षण किया गया)
• ndg-httpsclient (0.3.2 के साथ परीक्षण किया गया)
• pyasn1 (0.1.6 के साथ परीक्षण किया गया)

(या python3.2 या उच्चतर, जो हमेशा काम करता है)

ऐसा लगता है कि वर्तमान में एसएनआई के लिए अनुरोध और urllib3 दोनों टूट गए हैं। एक
समस्या यह है कि यदि कोई टाइमआउट = 5.0 जोड़ता है, तो कोड अलग-अलग व्यवहार करता है
टाइमआउट के बिना। दूसरी समस्या उन डोमेन के साथ है जो अस्तित्वहीन हैं।
परीक्षणों को केवल के आधार पर तुलना में अधिक एसएनआई डोमेन जोड़ने की आवश्यकता है
वर्टेक्स/httpbin/. वे दोनों एसएनआई के उपयोग को बिल्कुल भी नहीं दर्शाते हैं।

सोम, जून 10, 2013 को सुबह 4:57 बजे, थॉमस वेइसचुहो
नोटिफिकेशन@github.comलिखा :

यह अनुरोध/पैकेज/urllib3/contrib/pyopenssl. pyhttps://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/contrib/pyopenssl.py
:

• pyOpenSSL (0.13 के साथ परीक्षण किया गया)
• ndg-httpsclient (0.3.2 के साथ परीक्षण किया गया)
• pyasn1 (0.1.6 के साथ परीक्षण किया गया)

(या python3.2 या उच्चतर, जो हमेशा काम करता है)

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/kennethreitz/requests/issues/749#issuecomment -19187417
.

@pythonmobile यदि ऐसा है, और आपके पास एक अच्छा प्रतिलिपि प्रस्तुत करने योग्य परीक्षण मामला है, तो कृपया इसे urllib3 पर हाइलाइट करने वाली कोई समस्या खोलें। अनुरोधों में कोई एसएनआई-विशिष्ट कोड नहीं है (जहां तक ​​​​मुझे पता है), इसलिए वहां एक फिक्स हमें भी ठीक कर देगा।

जब तक urllib3 पहले से ही ठीक नहीं हो जाता है, जो इन दिनों बहुत कुछ हो रहा है। शाज़ो _et. अल._ बहुत बढ़िया हैं। @ t-8ch, क्या आप लोगों ने इसे पहले ही देखा/ठीक कर लिया है?

मुझे लगता है कि अगर हम अनुरोधों में परीक्षण लिखते हैं, तो उन्हें लिखना और परीक्षण करना आसान होता है, भले ही इसका मतलब केवल यह है कि यह ज्यादातर urllib3 कोड का परीक्षण करेगा। इस तरह, अनुरोधों में urllib3 के प्रत्येक आयात पर जांच करना आसान हो जाएगा, अगर sni टूटा हुआ है या नहीं और अलार्म उठाएं। मैं जल्द ही अनुरोध परीक्षण लिखूंगा।

क्षमा करें @pythonmobile , मैं सहमत नहीं हूँ। =)

एसएनआई स्पष्ट रूप से urllib3 कार्यक्षमता है। अगर एसएनआई urllib3 में टूटा हुआ है तो आपको पूरी तरह से उस प्रोजेक्ट को एक फिक्स, एक परीक्षण, या कम से कम एक बग रिपोर्ट प्रदान करनी चाहिए। जब वह परियोजना तय हो जाती है, तो अनुरोध जादुई रूप से भी तय हो जाएंगे (जब हम अगली बार urllib3 को अपडेट करते हैं, जिसे हम काफी बार करते हैं)। =)

जबकि अनुरोधों के लिए अधिक परीक्षण निश्चित रूप से चोट नहीं पहुंचाएंगे, जैसा कि @ लुकासा ने कहा था, यदि आप इसे वास्तव में तय करना चाहते हैं तो आपको urllib3 के लिए एक परीक्षण लिखना होगा। :)

हमारे पास पहले से ही इसी तरह के कई परीक्षण हैं, अगर आपको किसी मदद की ज़रूरत है तो मुझे पिंग करें।

ऐसा लगता है कि pyOpenSSL का टाइमआउट व्यवहार इससे अलग है
मानक एसएसएल मॉड्यूल:

from OpenSSL import SSL
import socket
import ssl

sock = socket.create_connection(('httpbin.org', 443), timeout=4.0)
ssl_sock = ssl.wrap_socket(sock)
ssl_sock.send('GET /ip HTTP/1.1\r\nHost: httpbin.org\r\n\r\n')
print(ssl_sock.recv(10000))

ctx = SSL.Context(SSL.TLSv1_METHOD)
sock = socket.create_connection(('httpbin.org', 443), timeout=4.0)
ctn = SSL.Connection(ctx, sock)
ctn.set_connect_state()

ctn.send('GET /ip HTTP/1.1\r\nHost: httpbin.org\r\n\r\n')
print(sock.read(10000))

यह एक WantReadError फेंकता है, वही जो urllib3 . से भी बाहर फेंका जाता है
टाइमआउट निर्दिष्ट करते समय।

दस्तावेज़ीकरण है
यह त्रुटि के बारे में कहने के लिए:

The operation did not complete; the same I/O method should be called again
later, with the same arguments. Any I/O method can lead to this since new
handshakes can occur at any time.

The wanted read is for dirty data sent over the network, not the clean data
inside the tunnel. For a socket based SSL connection, read means data coming at
us over the network. Until that read succeeds, the attempted
OpenSSL.SSL.Connection.recv, OpenSSL.SSL.Connection.send, or
OpenSSL.SSL.Connection.do_handshake is prevented or incomplete. You probably
want to select() on the socket before trying again. 

मुझे नहीं पता कि टाइमआउट को कैसे संभाला जाना चाहिए। क्या सॉकेट जादुई है
select() आह्वान पर टाइमआउट याद रखें या यह कार्य है
urllib3?
हाथ से टाइमआउट का ट्रैक रखना वास्तव में मज़ेदार नहीं लगता।

@pythonmobile गैर-मौजूद डोमेन से

@pythonmobile क्या आप shazow/urllib3#233 से परिवर्तनों को आजमा सकते हैं और देख सकते हैं कि कोड pyopenssl और टाइमआउट के साथ काम करता है या नहीं?

@t-8ch @pythonmobile : क्या आप लोग इस धागे को भी देख सकते हैं: https://github.com/kennethreitz/requests/issues/1522#issuecomment -22443282

इन अनुरोधों को urllib3 या अनुरोधों के अंदर एक इकाई परीक्षण में प्राप्त करना अच्छा होगा।

इन्हें एक इकाई परीक्षण के रूप में प्राप्त करने में समस्या यह है कि वे केवल बहुत विशिष्ट विन्यास में दिखाई देते हैं। उदाहरण के लिए, मैं अपने किसी भी सिस्टम पर इस मुद्दे के दूसरे भाग या #1522 को कभी भी पुन: पेश नहीं कर पाया, चाहे वह विंडोज, ओएस एक्स या उबंटू हो। इसलिए मैंने @pythonmobile को एक प्रतिलिपि प्रस्तुत करने योग्य इकाई परीक्षण के लिए कहा। अगर हमें कोई मिल जाता है, तो हम इसके खिलाफ विकास कर सकते हैं, अन्यथा हम उम्मीद कर रहे हैं कि @ t-8ch एक प्रतिभाशाली बना रहेगा और हमारी सभी समस्याओं को urllib3 पर जादुई रूप से ठीक कर देगा।

ध्यान दें: @ t-8ch, मुझे नहीं लगता कि मैं यहां और urllib3 दोनों पर आपके काम के लिए आपको पर्याप्त धन्यवाद देता हूं। तुम कमाल हो। =डी:केक::अनानास::केला::कुकी::बीयर्स:

@lukasa धन्यवाद: मुस्कान: मुझे लगता है कि मैं भविष्य में कुछ समय के लिए खुद को AUTHORS.txt जोड़ सकता हूं।

@ t-8ch करो। :+1:

Shazow/urllib3#233 (अब urllib3 मास्टर में खींचा गया) में परिवर्तन मेरे लिए समस्या को ठीक करता है ( SSLError('bad handshake', WantReadError()) ) जो कुछ यूआरएल के लिए हुआ था, कुछ बार, कुछ कॉन्फ़िगरेशन में: rage4:। क्या हम इसे अनुरोध मास्टर में खींच सकते हैं?

@rcoup जब हम 2.0 जारी करेंगे तो हम एक अप-टू-डेट संस्करण को अनुरोधों में शामिल करेंगे। =)

मैं पायथन 2.7.6 चला रहा हूं और pyOpenSSL स्थापित नहीं कर सकता। मैं htis पोस्ट में काम arounds की कोशिश की है -> https://stackoverflow.com/questions/18578439/using-requests-with-tls-doesnt-give-sni-support/18579484#18579484

मैं पायथन द्वारा भी अपग्रेड नहीं कर सकता। कोई अन्य उपाय?

मैं अनुरोध कर रहा हूं कि हम "inject_into_urllib3 ()" के बिना शर्त उपयोग (यदि मौजूद हैं) पर पुनर्विचार करें।

7 साल पहले जोड़ा गया, लक्ष्य "पायथन 2 के लिए एसएनआई समर्थन जोड़ना" था

"urllib3.contrib.pyopenssl.inject_into_urllib3 ()" को "PyOpenSSL-समर्थित SSL-समर्थन के साथ बंदर-पैच urllib3" के रूप में वर्णित किया गया है।
(https://github.com/urllib3/urllib3/blob/master/src/urllib3/contrib/pyopenssl.py)

औचित्य:
1: सुरक्षा/स्थिरता: किसी तृतीय पक्ष पुस्तकालय के लिए मानक पुस्तकालय उपयोग को स्वैप करने के लिए बंदर पैचिंग तर्कसंगत रूप से अधिक सर्जिकल होना चाहिए, खासकर एसएसएल के लिए। यदि पैच Python2 में समर्थन के लिए है, तो कम से कम एक प्रमुख संस्करण की जांच करें। या इससे भी बेहतर, जांचें कि क्या एसएनआई समर्थन पहले से मौजूद है ssl.HAS_SNI ।

2: अनावश्यक: 10 दिसंबर 2014 तक, Python 3.4 के ssl मॉड्यूल की संपूर्णता को Python 2.7.9 के लिए बैकपोर्ट कर दिया गया है। औचित्य के लिए पीईपी 466 देखें। https://www.python.org/downloads/release/python-279/। यह > v2.7.9 . के लिए मानक पुस्तकालय में SNI समर्थन को सक्षम बनाता है

3: अनम्य: जैसा कि लागू किया गया है, इस व्यवहार को अक्षम करने का कोई तरीका नहीं है। requests pyopenssl संदर्भ के उपयोग को रोकने का एकमात्र विकल्प मेरे पूरे पायथन पर्यावरण के लिए pyopenssl को अनइंस्टॉल करना है।