Requests: OpenSSL.SSL.Error: [("إجراءات SSL" ، "SSL3_GET_RECORD" ، "فشل فك التشفير أو سجل تالف mac")]

شكرا على هذا!

نعم ، هذا ليس خطأ طلبًا حقًا ، كما يبرز سؤال SO: إنه خطأ Debian أو OpenSSL.

مع ذلك ، سيكون الحل المحتمل امتدادًا لمحول النقل المعروض على مدونتي ، هنا: https://lukasa.co.uk/2013/01/Choosing_SSL_Version_In_Requests/

إنها مشكلة حقيقية وليس لدي تأكيد على أن الحل البديل يعمل. الأمر الأكثر صعوبة هو أن برنامج التشغيل الآلي الخاص بي الذي استخدم للاستعلام عن خادم كل ساعة لبضع مئات من الطلبات بدأ يفشل فجأة ، حتى بدون أن أغير أي شيء على الجهاز. أعتقد أنهم ربما قاموا بتغيير تكوين خادم الويب.

ومع ذلك ، لا تزال المشاكل تحدث في أحدث توزيعة Ubuntu ، مع جميع التصحيحات والإصدار الأخير من OpenSSL عمره عام واحد. نحن بحاجة إلى تنفيذ حل بديل لهذا.

أيضًا ، جربت الحل البديل المحدد في منتديات OpenSSL لكنه لا يعمل ، سأحاول أسلوبك وأرى.

أوافق على أنها مشكلة حقيقية. لا أوافق بالضرورة على أن الطلبات تحتاج إلى حل بديل لكل خطأ في أي من تبعياتنا.

ما لم يتضح لي في هذا الوقت هو مدى خطورة هذا الخطأ ، ومدى انتشاره ، ومدى سهولة حله. كما أنه ليس من السهل بالنسبة لي العثور على هذه الأشياء اليوم: فأنا في مؤتمر ولن يكون لدي وقت بالقرب من جهاز كمبيوتر محمول. سيكون من المفيد أن يلقي @ sigmavirus24 نظرة: وإلا فسوف يتعين علي البحث فيه غدًا.

الشيء الأساسي الذي يجب معرفته هو أن OpenSSL كان لديه أخطاء أخرى في الماضي لم نتعامل معها في كود الطلبات الأساسي. والجدير بالذكر ، 0.9.8f (على ما أعتقد) أن السفن التي تعمل بنظام OS X 10.8 بها خطأ مشابه لم نتعامل معه أبدًا.

لسنا مطالبين بإصلاح كل خطأ في جميع تبعياتنا ، خاصة تلك الضمنية. قد نصلح هذا ، لكني لا أعرف حتى الآن.

لاحظ أن الحل البديل هو استخدام إصدار مختلف من OpenSSL. فقط أقول.

لم يعمل الحل الخاص بك هذه المرة ، لقد جربته ونفس الخطأ. وفيما يتعلق باستخدام opensl جديد ، فهذا ليس بالأمر السهل على الإطلاق ، فإن opensl مرتبط جيدًا بالنظام وأتصور أن تثبيت واحد آخر لن يؤدي إلا إلى المزيد من المشاكل.

إذا كان لدينا حل عملي ، فسيكون ذلك جيدًا ، ولا أمانع في تطبيق التصحيح على هذا البرنامج النصي ، لكنه لا يعمل. حاولت مع ssl_version = ssl.PROTOCOL_TLSv1

... أحاول الآن بناء الحد الأدنى من حالة الاختبار.

عفوًا ، يبدو أن الأمر كان خداعًا ، لا علاقة له بهذا. بدلاً من ذلك ، يبدو أنه مرتبط بالمعالجة المتعددة. كنت أستخدم المعالجة المتعددة من أجل تنفيذ الطلبات على 10 مؤشرات ترابط ، لتسريع العملية. نجح هذا بشكل جيد لأسابيع ولكنه توقف فجأة عن العمل منذ يومين ... مع هذا الخطأ.

كيف يبدو رمز المعالجة المتعددة الخاص بك؟ إذا كنت تشارك Session كائنات عبر العمليات ، فستحدث أشياء سيئة. =)

لم أكن أشارك أي جلسة ، في الواقع كنت أستدعي وظيفة في كل مؤشر ترابط ، وأمرر معلمة وداخل هذه الوظيفة لدي الكود الخاص بي الذي كان ينشئ جلسة ، وينفذ 2-3 طلبات ويعود. أعلم ، غريب.

هذا غريب جدا. هل يمكن استنساخه بسهولة؟

ssbarnea هل يمكنك على الأقل مشاركة عنوان URL حتى نتمكن من محاولة إعادة إنتاجه؟ أعتقد حتى الآن أن لدينا معلومات كافية تقريبًا ، نحتاج فقط إلى عنوان URL أو خصائص الخادم لإعادة إنتاجه:

• المعالجة المتعددة باستخدام _10 خيوط_
• الوظيفة التي تُنشئ جلسة وتُقدم أكثر من طلب (ظاهريًا إلى نفس الخادم) معها.

بدأت في الحصول على هذا أيضًا تشغيل https://github.com/edx/dyno-slayer

بدأت المشكلة عند التغيير:

DEFAULT_MIN_TIMING_WINDOW = 60
DEFAULT_MAX_TIMING_WINDOW = 120

إلى:

DEFAULT_MIN_TIMING_WINDOW = 20
DEFAULT_MAX_TIMING_WINDOW = 30

crizCraig لست على دراية بهذا المشروع. ما هي أهمية تلك القيم؟ هل هم:

• قيم ملف التكوين؟
• قيم البيئة؟
• آخر؟

عذرًا ، هؤلاء فقط يحددون مدة زمنية لأخذ عينات من سجلات heroku عبر واجهة برمجة التطبيقات الخاصة بهم. البرنامج بأكمله هو هذا الملف:

https://github.com/edx/dyno-slayer/blob/master/scripts/slayer.py

نحتاج إلى تشخيصات أفضل بكثير مما أخشى. =) هل يمكنك تزويدنا بتتبع ، على سبيل المثال؟

أتساءل عما إذا كان بإمكان شخص ما يعمل catsby ، هل يمكنك أن تعطينا بعض المعلومات حول تكوين SSL في صندوق Heroku الافتراضي؟ هل يمكنك توجيهنا إلى شخص يستطيع؟

crizCraig بينغ. =)

أواجه هذه المشكلة في Windows 7 مع Python 2.7.9 x32

SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:581)

zvodd هل حاولت فرض مفاوضات SSL في إصدارات مختلفة ، وفقًا لهذه المقالة ؟

مغلق لعدم النشاط.

ركض في هذه المشكلة باستخدام المعالجة المتعددة. لم أتمكن من إصلاحه.

maxcountryman ، هل يمكنك تقديم أي من التفاصيل التي

@ sigmavirus24 حسنًا ، أنا لا أستخدم Heroku. ما هي التفاصيل الأخرى التي تريدها؟

تضمين التغريدة

• نسختك من python و opensl
• نظام التشغيل والإصدار
• مقتطف رمز كسر الحد الأدنى
• إذا كان ذلك ممكنًا ، فإن عنوان URL العام الذي يتسبب في حدوث الخطأ (مع مقتطف الشفرة المذكور)

مرحبًا Lukasa @ sigmavirus24 @ t-8ch ،
هل مقالتك (https://lukasa.co.uk/2013/01/Choosing_SSL_Version_In_Requests/) متوافقة مع Python 3؟ هل من الصواب حل المشكلة الحالية عن طريق تحديث python إلى الإصدار 2.7.9؟

ulandj يجب أن تكون المقالة متوافقة مع Python 3. الترقية إلى Python 2.7.9 ستحل الكثير من المشاكل.

Lukasa ie بعد الترقية إلى Python 2.7.9 لست بحاجة إلى استخدام المحول في المقالة ، أليس كذلك؟ و

import requests
conn = requests.Session()
conn.put(url, data=body, headers=headers)
conn.delete(url, data=body, headers=headers)

ستعمل مع أي عدد من العمليات المتعددة؟

إذا كنت تواجه هذه المشكلة مع المعالجة المتعددة ، فلم يتم إعطائي مطلقًا سيناريو إعادة بروروها ، لذلك لا أعرف في الواقع ما يحدث. إذا كان بإمكانك توضيح المشكلة بقليل من نموذج التعليمات البرمجية ، فأنا أرغب في رؤيتها.

حسنًا ، سنقوم أولاً بالترقية إلى python 2.7.9 وسنحاول التشغيل بمعالجة متعددة. إذا ظهر هذا الخطأ مرة أخرى ، فسأعلمك بذلك. شكرا.

Lukasa يقول عميلنا أن لديهم الخطأ التالي:

Traceback (most recent call last): 
File "/opt/SketchSync/WorkersApp.py", line 230, in run self.producer.release_job(self.worker_id, payload, done) 
File "/opt/SketchSync/SketchSyncProducer.py", line 88, in release_job self.queue.delete_job(payload) 
File "/opt/SketchSync/SketchSyncProducer.py", line 177, in delete_job self.queue.delete(mid) 
File "/usr/local/lib/python2.7/site-packages/iron_mq.py", line 58, in delete result = self.client.delete(url) 
File "/usr/local/lib/python2.7/site-packages/iron_core.py", line 233, in delete retry=retry, body=body) 
File "/usr/local/lib/python2.7/site-packages/iron_core.py", line 152, in request r = self._doRequest(url, method, body, headers) 
File "/usr/local/lib/python2.7/site-packages/iron_core.py", line 117, in _doRequest r = self.conn.delete(url, data=body, headers=headers) 
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 527, in delete return self.request('DELETE', url, **kwargs) 
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 456, in request resp = self.send(prep, **send_kwargs) 
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 559, in send r = adapter.send(request, **kwargs) 
File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 382, in send raise SSLError(e, request=request) 
SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1750) 

هل تقول عن شيء ما؟

استخدام:
الثعبان (2.7.9)
الطلبات (2.3.0)

ulandj يبدو أنك http://stackoverflow.com/a/3724938/1953283

@ sigmavirus24
تعتقد أنه إذا قمت بنقل هذا السطر من التعليمات البرمجية (من مُنشئ الفصل) - https://github.com/iron-io/iron_core_python/blob/master/iron_core.py#L162 هنا - https://github.com/ iron-io / iron_core_python / blob / master / iron_core.py # L188 ، فهل ستعمل بدون أخطاء؟

ulandj fwiw ، الكود الذي يكسر في طلبي يتضمن نفس غلاف IronIO.

ulandj لقد أجريت التغييرات التي اقترحتها ويبدو أن الأمور تسير بشكل جيد حتى الآن على جهاز التطوير المحلي الخاص بي. يجب أن أكون قادرًا على طرح هذا على الإطلاق قريبًا حيث تكون الأخطاء أكثر شيوعًا.

قامulandj بتدوير التغييرات المذكورة أعلاه إلى التدريج وكان الإبحار سلسًا منذ ذلك الحين. أشك في أنه سيتم دمجهم في المنبع لأنك تفقد فائدة الجلسة تمامًا ولكن على أي حال يبدو أنها تعمل على إصلاحها.

maxcountryman شكرا ،
عرضنا على عملائنا تثبيت iron_core من فرع أولان -متعدد المعالجة-sslerror . سوف نراقبه. آمل أن تساعد "طلبات" النقل في حل خطأ SSL في المعالجة المتعددة.

Lukasa وصف بسيط

1. جعل الدورة في العملية الرئيسية
2. قدم بعض الطلبات إلى موقع يدعم SSL
3. ابدأ عمليتي معالجة متعددة
4. في البداية ، قم بإجراء المزيد من الطلبات لنفس الموقع الذي يدعم بروتوكول SSL (لذلك يبدأ تجميع الاتصال)
5. في الثانية ، انتظر قليلاً ، ثم قدم طلبًا إلى نفس الموقع الذي يدعم SSL

لا يمكنني نشر البرنامج النصي الخاص بي الذي يصل إلى هذا الحد ، لكنني سأرى ما إذا كان بإمكاني إنشاء نص برمجي بسيط يعيد إنتاج هذا باستخدام httpbin.

لماذا يحدث هذا: تشترك العمليتان الفرديتان في حالة SSL في البداية ، وتستخدمان نفس المقبس للاتصال ، ولكن بمجرد أن يقدم أحدهما طلبًا ، تصبح الحالة غير متزامنة ، لذلك عندما يحاول الآخر استخدامها ، يفشل فك تشفير SSL .

بعض الإصلاحات الممكنة:

• تخلص من اتصالات SSL من تجمع الاتصال عند إلغاء اختيار الجلسة وإغلاق كائنات المقبس المرتبطة بها
  
  
  
  • هذا جيد لأن إغلاق كائن مأخذ التوصيل يغلق فقط واصف ملف تلك العملية؛ لن يتم إغلاق الاتصال الأساسي حتى يتم إغلاق كافة واصفات الملفات التي تشير إليه
  
  
  • افعل ذلك عند إلغاء الالتقاط بدلاً من منع الاتصالات من الوصول إلى المخلل بحيث يمكنك تنظيف واصفات الملفات في العمليات الفرعية
  
  
• تخلص من مجموعة الاتصال بالكامل عند عدم التقاطها
  
  
  
  • ربما تكون أفضل فكرة ، لأن الأمور على الأرجح ستنهار
  
  
• تحذير / تنفجر عند إلغاء انتقاء جلسة بها SSL / أي اتصالات في تجمع الاتصال الخاص بها

نص الاستنساخ:

#!/usr/bin/env python3.4

import multiprocessing
import requests
import signal
import sys

session = None
stop = None

def sub_1():
    signal.signal(signal.SIGINT, signal.SIG_IGN)
    while not stop.wait(2):
        session.get('https://httpbin.org/ip')

def sub_2():
    signal.signal(signal.SIGINT, signal.SIG_IGN)
    while not stop.wait(20):
        session.get('https://httpbin.org/ip')

if __name__ == '__main__':
    session = requests.Session()
    session.get('https://httpbin.org/ip')
    stop = multiprocessing.Event()
    sub_1_process = multiprocessing.Process(target=sub_1)
    sub_1_process.start()
    sub_2_process = multiprocessing.Process(target=sub_2)
    sub_2_process.start()
    while True:
        try:
            sub_1_process.join()
            sub_2_process.join()
            sys.exit(0)
        except (KeyboardInterrupt, SystemExit):
            if not stop.is_set():
                stop.set()
            else:
                raise

نتيجة التتبع بعد 20 ثانية تقريبًا:

Process Process-2:
Traceback (most recent call last):
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 376, in _make_request
    httplib_response = conn.getresponse(buffering=True)
TypeError: getresponse() got an unexpected keyword argument 'buffering'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 559, in urlopen
    body=body, headers=headers)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 378, in _make_request
    httplib_response = conn.getresponse()
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/http/client.py", line 1227, in getresponse
    response.begin()
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/http/client.py", line 386, in begin
    version, status, reason = self._read_status()
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/http/client.py", line 348, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/socket.py", line 378, in readinto
    return self._sock.recv_into(b)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/ssl.py", line 748, in recv_into
    return self.read(nbytes, buffer)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/ssl.py", line 620, in read
    v = self._sslobj.read(len, buffer)
ssl.SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1748)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/adapters.py", line 376, in send
    timeout=timeout
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 588, in urlopen
    raise SSLError(e)
requests.packages.urllib3.exceptions.SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1748)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap
    self.run()
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "test.py", line 19, in sub_2
    session.get('https://httpbin.org/ip')
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/sessions.py", line 480, in get
    return self.request('GET', url, **kwargs)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/Users/dwfreed/.pyenv/versions/3.4.4/lib/python3.4/site-packages/requests/adapters.py", line 447, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1748)

لقد قمت بعمل نسخة نصية في الإصدار 3.4 ، ولكن من المحتمل أن تكون نفس المشكلة في كل إصدار مدعوم بالطلبات والمعالجات المتعددة. هذا البرنامج النصي هو في الأساس ما يفعله الكود الخاص بي ، باستثناء الإشارة إلى httpbin بدلاً من ما أضربه بالفعل.

أنا مرتبك قليلاً من تشخيصك هنا: لا أعتقد أنه صحيح تمامًا.

والسبب هو أن تجمع الاتصال لا يتم نقله عبر الانتقاء / إلغاء الانتقاء. نحن نطلق صراحةً على init_poolmanager عند إلغاء الانتقاء لمنحنا تجمع اتصال جديد. ومع ذلك ، هذا لتوفير البرنامج النصي repro: سأتعمق في الأمر وأرى ما إذا كان بإمكاني العثور على ما يحدث.

Lukasa أنا أتعامل مع الاتصال باستخدام وكيل شفاف. تم إجراء اتصال واحد فقط.

عذرًا ، الجلسة لا تتأخر على الإطلاق ، لأن طريقة البدء الافتراضية للمعالجة المتعددة على أنظمة Unix هي fork ، والتي تعتمد على دلالات COW بدلاً من ذلك. إذا قمت بالتبديل إلى طريقة بدء النشر (وقمت بإصلاح البرنامج النصي لتمرير الجلسة كمعامل) ، فسيتم اختيار الجلسة ، مما يؤدي إلى مسح تجمع الاتصال.

نعم ، اكتشف اختباري هذا هنا أيضًا. =) إذن هذه المشكلة هي مجرد مشكلة جوهرية تتعلق بالمآخذ.

عندما تفترق ، يجب على أي من الوالدين أو الطفل إغلاق واصفات الملفات الخاصة بهم ، لأن استخدامها من سلاسل مختلفة أمر سيء حقًا. هذا يعني في الأساس أنه إما أنه لا ينبغي عليك مشاركة جلسة عبر العمليات - على الإطلاق - ، أو يجب عليك التأكد من أنه عند تمرير جلسة إلى عملية أخرى ، فإنك تفقدها في العملية الأصلية التي عقدت فيها.

لا أعتقد أن هناك الكثير مما يمكننا فعله حيال ذلك.

أو تنظيف تجمع الاتصال يدويًا في عمليات الأطفال. لإصلاح ذلك في الطلبات ، ستحتاج إلى خطاف after_fork ، والذي لا أعتقد أنه يتعرض له بواسطة python (تحتوي بعض وحدات stdlib على كود ما بعد الانقسام الذي يتم استدعاؤه من كود C بعد الشوكة ، لكنها خاصة ). قد يكون من الجيد أن يكون لديك وظيفة after_fork () على كائنات الجلسة ، وتوثيق أنه يجب استدعائها بعد أي استدعاء لـ os.fork () ، بما في ذلك عند استخدام المعالجة المتعددة مع fork كطريقة البداية.

لم أذكر هذا النهج صراحة لأنني أعتقد أنه من المستحيل بالنسبة لنا أن نفعل ذلك بشكل معقول.

على سبيل المثال ، هناك شيء واحد قد ترغب في القيام به وهو تكوين جلسة على العملية الرئيسية ثم تمريرها إلى الطفل: في هذه الحالة ، تريد أن يحتفظ المثيل الفرعي باتصالاته ويخسرها الوالد.

أعتقد أن هذا شيء يجب على المستخدم أن يقرر القيام به: إذا كنت تشارك الجلسات عبر العمليات على الإطلاق (وهو ما أوصي بعدم القيام به إذا كان ذلك ممكنًا) ، فأنت بحاجة إلى إجراء مكالمة حول ما يجب القيام به عندما شوكة.

حسنًا ، يمكنك أن تذكر في التوثيق الحالات التي تريد استدعاء after_fork () ، ومتى لا تريد ذلك. في حالتي ، كل ما يهمني هو تعيين بعض الرؤوس المحددة ، لكني أحتاج إلى بعض البيانات من واجهة برمجة التطبيقات قبل أن أتمكن من بدء تشغيل الأطفال (مهلات استدعاءات stop.wait () في الأطفال مشتقة بالفعل من واجهة برمجة التطبيقات ، من أجل على سبيل المثال) ، ويبدو أنه من المهم بالنسبة لي أن أقوم بإعداد جلسة 3 مرات باستخدام نفس رمز الإعداد بالضبط.

أفترض أن أحد الخيارات في حالتي هو شحن طلبات PreparedRequests إلى العملية الرئيسية لإرسال الردود ثم إعادة شحنها عبر قوائم الانتظار. أو يمكنني العودة إلى وضع مؤشرات الترابط ، نظرًا لأن عبء العمل الفعلي للمعالجة خفيف جدًا ؛ يبدو هذا أسهل في حالتي (ولكن قد لا يكون الحل الأفضل للآخرين).

تكاليف إعداد جلسة dwfreed منخفضة للغاية: لا يتعين على الجلسات أن تفعل الكثير من أجل الإعداد. على وجه الخصوص ، نظرًا لأنه يتعين عليك انتظار عودة واجهة برمجة التطبيقات قبل إعداد الأطفال ، أعتقد أنه يمكنك على الأرجح التفاف الإعداد كجزء من الوظيفة التي تستدعيها في عملية الخلفية وتصبح غير ملحوظة بشكل أساسي.

يأتي هذا من أجل سبب توتري بشأن كتابة التوثيق لهذا الأمر: لا أعتقد أنه يمكننا تقديم أكثر من مجرد نصيحة عامة تتلخص في: لا تشارك الجلسات عبر العمليات ، فكر جيدًا فيما إذا كنت تريد مشاركة الجلسات عبر الخيوط ، عند كتابة رمز متزامن ، حاول اعتماد أنماط تصميم متزامنة جيدة.

أي شيء أكثر من ذلك هو مجرد تقييدية للغاية فيما يتعلق بالنصائح.

أعلم أن هذا طلب قديم ولن يتم حله من خلال مشروع الطلبات ، ولكن عندما تتعثر في googling حول هذه المشكلة باستخدام كود python ، فإنك دائمًا ما تعود إلى هذه المشكلة بالذات.

يحدث أنه في حالتي كان يحدث مع "boto" (الذي يستخدم "الطلبات" تحت الغطاء). يحدث أن يحاول boto القيام بتجميع اتصالات ذكي والذي ينقطع بشكل سيئ عند التفرع. يتم تعطيل تجميع الاتصال الذكي هذا عند التشغيل على Google App Engine. يكتشف Boto ما إذا كنت تستخدم App Engine مع وجود 3 متغيرات البيئة التالية. يؤدي ضبطها إلى اختفاء الخطأ تمامًا: USER_IS_ADMIN=fake CURRENT_VERSION_ID=fake APPLICATION_ID=fake .

مرة أخرى ، أعذر البريد العشوائي هنا ، آمل أن يكون مفيدًا لشخص ما :-) واستمر في العمل الرائع مع الطلبات !!!

jbbarth أنت بطلي. بدأ هذا الخطأ يحدث لي على boto حيث أضفت المعالجة المتعددة. الحل الخاص بك لا يعمل بالنسبة لي (حتى الآن). ما إصدار الطلبات الذي تستخدمه؟

fuzzyami أعتقد أنه كان 2.10 ، إلى جانب boto 2.38 أو 2.39. ربما تغيرت الأساليب البحثية في boto ، أوصيك بالنظر في آلية تجميع الاتصال الخاصة بهم أو grep متغيرات البيئة التي كنت أشير إليها. حظا طيبا وفقك الله! :)

لدي نفس المشكلة مع

boto (2.47.0)
boto3 (1.3.1)
botocore (1.5.79)
requests (2.18.1)

jbbarth شكرا جزيلا على الحل.