कर्ल वापस "अतिरिक्त सामान ठीक नहीं है" क्यों लौट रहा है?

Question

मैं एक पायथन एप्लिकेशन लिख रहा हूं जो curl के माध्यम से सोशल मीडिया एपीआई से पूछताछ करता है।

अतिरिक्त सामान नहीं ठीक transfer.c: 1037: 0 0

असामान्य बात है अलग सर्वर मैं क्वेरी (गूगल +, रेडिट, ट्विटर, फेसबुक, अन्य) के अधिकांश cURL शिकायत है जब एप्लिकेशन पहली बार शुरू होता है, तो प्रत्येक सेवा की प्रतिक्रिया इस पंक्ति को एक या दो बार फेंक देगी। कुछ मिनटों के बाद, लाइन कई बार दिखाई देगी। स्पष्ट रूप से curl कुछ ऐसी पहचान कर रहा है जिसे वह पसंद नहीं करता है। लगभग आधे घंटे के बाद, सर्वर समय समाप्त हो जाते हैं और इस लाइन को कई बार दोहराया जाता है, इसलिए यह एक वास्तविक समस्या दिखा रहा है।

मैं इसका निदान कैसे कर सकता हूं? मैंने वायरसहार्क का उपयोग करने के लिए अनुरोध और प्रतिक्रिया शीर्षकों को उन विसंगतियों की खोज करने के लिए प्रयास किया जो कर्ल को शिकायत कर सकती हैं, लेकिन सभी वायरसहार्क की जटिलता के लिए केवल हेडर को अलग करने और प्रदर्शित करने का एक तरीका प्रतीत नहीं होता है।

यहाँ कोड के प्रासंगिक हिस्सा है:

output = cStringIO.StringIO() 
c = pycurl.Curl() 
c.setopt(c.URL, url) 
c.setopt(c.USERAGENT, 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0') 
c.setopt(c.WRITEFUNCTION, output.write) 
c.setopt(c.CONNECTTIMEOUT, 10) 
c.setopt(c.TIMEOUT, 15) 
c.setopt(c.FAILONERROR, True) 
c.setopt(c.NOSIGNAL, 1) 

try: 
    c.perform() 
    toReturn = output.getvalue() 
    output.close() 
    return toReturn 

except pycurl.error, error: 
    errno, errstr = error 
    print 'The following cURL error occurred: ', errstr 

Answer 1

मैं 99.99% यकीन है कि यह किसी भी HTTP हेडर में वास्तव में नहीं है, बल्कि libcurl द्वारा stderr को मुद्रित किया जा रहा है कर रहा हूँ। संभवतः यह आपके बीच हेडर लॉगिंग करने के बीच होता है, यही कारण है कि आप उलझन में थे।

वैसे भी, "additional stuff not fine" curl transfer.c के लिए एक त्वरित खोज a recent change in the source कर दिया जहां वर्णन है:

Curl_readwrite: हटाने डिबग आउटपुट

पाठ "अतिरिक्त सामान ठीक नहीं" पाठ डिबग प्रयोजनों के लिए जोड़ा गया था एक पहले, लेकिन यह वास्तव में किसी की मदद नहीं कर रहा है और किसी कारण से कुछ लिनक्स वितरण डीबग जानकारी के साथ निर्मित libcurls प्रदान करते हैं वर्तमान और इस प्रकार (बहुत अधिक) उपयोगकर्ताओं को वें पढ़ने के लिए मिलता है जानकारी है

तो, यह मूल रूप से हानिरहित है, और एकमात्र कारण आप इसे देख रहे हैं कि आप (शायद अपने linux distro से) था कि पूर्ण डिबग लॉगिंग सक्षम (curl लेखक के बावजूद यह सोच कर कि है libcurl का निर्माण हो गया एक बुरा विचार)। तो आपके पास तीन विकल्प हैं:

1. इसे अनदेखा करें।
2. libcurl के बाद के संस्करण में अपग्रेड करें।
3. डीबग जानकारी के बिना libcurl पुनर्निर्माण करें।

आप (जैसा कि ऊपर जुड़े) transfer.c के लिए libcurl स्रोत देख सकते हैं समझने के लिए curl के बारे में शिकायत कर रहा है की कोशिश करना, और संभवतः एक ही आस-पास के लिए मेलिंग सूची पर धागे देखने के समय या सिर्फ सूची ईमेल और पूँछो।

हालांकि, मुझे संदेह है कि वास्तव में वास्तविक समस्या के लिए प्रासंगिक नहीं हो सकता है, यह देखते हुए कि आप इसे शुरुआत से भी सही देख रहे हैं।

1. कर्ल में बग, या जिस तरह से आप यह प्रयोग कर रहे हैं:

   वहाँ तीन स्पष्ट चीजें हैं जो गलत यहाँ जा रहा जा सकता है।

2. आपके नेटवर्क सेटअप में कुछ गड़बड़ है (उदाहरण के लिए, आपका आईएसपी आपको बहुत से आउटगोइंग कनेक्शन बनाने या 30 मिनट में बहुत से बाइट्स का उपयोग करने के लिए बंद कर देता है)।
3. आप जो कुछ कर रहे हैं वह सर्वर को यह सोच रहा है कि आप स्पैमर/डीओएस हमलावर/जो कुछ भी हैं और वे आपको अवरुद्ध कर रहे हैं।

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

आप समय के आधार पर मामलों 2 और 3 के बीच अंतर करने में सक्षम हो सकते हैं। यदि सभी सेवाएं एक बार में समाप्त होती हैं- खासकर अगर वे अलग-अलग समय पर उन्हें मारना शुरू करते हैं तो भी वे ऐसा करते हैं (उदाहरण के लिए, आप फेसबुक के 15 मिनट बाद Google+ को मारना शुरू करते हैं, और फिर भी वे फेसबुक पर हिट करने के 30 मिनट बाद दोनों ही समय निकालते हैं) , यह निश्चित रूप से मामला है 2. यदि नहीं, तो यह मामला हो सकता है 3.

यदि आप इनमें से तीनों को रद्द करते हैं, तो आप अन्य चीजों की तलाश करना शुरू कर सकते हैं जो गलत हो सकते हैं, लेकिन मैं यहां शुरू करूंगा।

या, यदि आप हमें बताते हैं कि आपका ऐप क्या करता है (उदाहरण के लिए, क्या आप जितनी जल्दी हो सके सर्वर को हिट करने की कोशिश करते हैं? क्या आप अलग-अलग उपयोगकर्ताओं की ओर से कनेक्ट करने का प्रयास करते हैं? क्या आप एक देव कुंजी या एंड-यूजर ऐप की इत्यादि का उपयोग कर रहे हैं?), यह उन सेवाओं के साथ अधिक अनुभव वाले किसी और के लिए संभव हो सकता है।

Answer 2

मैं इससे असहमत हूं - मुझे एक ही संदेश मिलता है जब एक बिगिप एलटीएम बाहरी वीआईपी पते के माध्यम से वेबसाइट पर कॉल करने का प्रयास किया जाता है।

उदाहरण के लिए:

मैं फोन वेबसाइट http://11five.10.10.10/index.html (आईपी पते इस मामले में यादृच्छिक है)। बिग एफ 5 वर्चुअल सर्वर से जुड़े पूल के माध्यम से यातायात को दो आंतरिक वेब सर्वर (17two.20.0.10 और 17two.20.0.11) में संतुलित करना चाहिए।

इस मामले में, बाहरी स्रोत (आंतरिक क्लाइंट) से आने वाले अनुरोध को टीसीपी 80 पर वीआईपी पते पर आने वाले अनुरोध को दो वेब सर्वरों के बीच राउंड रॉबिन होना चाहिए। मुझे क्या लगता है कि सभी सर्वरों को प्रारंभिक SYN पैकेट प्राप्त होता है और कभी भी एक SYN-ACK वापस नहीं मिलता है।

यदि मैं स्थानीय सबनेट के भीतर एक टर्मिनल पर बैठता हूं जहां असली सर्वर रहते हैं, तो मैं index.html वेबपृष्ठ "wget" कर सकता हूं - 17two.20.0.11 से http://17two.20.0.10} /index.html से सोर्स किया गया।

बाहरी से आ रहा है, मुझे * अतिरिक्त सामान ठीक नहीं है ट्रांसफर.c: 1037 0 0 संदेश।

आप यह कहकर सही कह रहे हैं कि यह libcurl लाइब्रेरी के पुराने संशोधन में कर्ल के लिए डीबग तंत्र में निर्मित है लेकिन मैं नीचे दिए गए कथन से असहमत हूं;

A bug in curl, or the way you're using it. 
Something wrong with your network setup (e.g., your ISP cuts you off for making too many outgoing connections or using too many bytes in 30 minutes). 
Something you're doing is making the servers think you're a spammer/DoS attacker/whatever and they're blocking you. 

क्या कभी इस खड़ी कर रहा है पर्यावरण के भीतर एक नेटवर्किंग मुद्दे की वजह से है, IE .. वेब सर्वर यातायात वापस मूल स्रोत में नहीं लौट सकते हैं और इसलिए इस या दो त्रुटि प्रदर्शित करता है, वहाँ कुछ गड़बड़ है अनुरोध शीर्षलेख और वेब सर्वर से प्रतिक्रिया वापस।

इस मामले में मैं यह कहने का विकल्प चुनूंगा कि जब मैंने स्थानीय सबनेट में एक परीक्षण होस्ट से मूल अनुरोध पर विभिन्न यूआरआईएस का उपयोग करके एक कर्ल किया था, तो मैं index.html वेब पेज को पुनर्प्राप्त कर सकता था ठीक। इसका तात्पर्य यह है कि सर्वर FQDN और सर्वर का संक्षिप्त नाम उपयोग करके कनेक्शन सुन रहा है और स्वीकार कर रहा है।

मेरा मानना ​​है कि यह त्रुटि यह सुझाव देने के लिए है कि कर्ल को एक प्रतिक्रिया मिली है कि यह अनिश्चित है और इसलिए उपर्युक्त त्रुटि उत्पन्न करता है। कर्ल विकसित करने या स्रोत कोड पढ़ने के बिना, मैं आगे टिप्पणी नहीं कर सकता।

इस तर्क से संबंधित कोई भी अतिरिक्त प्रतिक्रिया स्वागत होगी - सभी नई चीजों को सीखने के लिए।

एंडी

Answer 3

कर्ल में बग, या जिस तरह से आप यह प्रयोग कर रहे हैं इस बात की पुष्टि।

Systen जानकारी: लिनक्स alt 3.2.0-4-amd64 # 1 SMP डेबियन 3.2.63-2 + deb7u1 x86_64 जीएनयू/लिनक्स

मैं नवीनीकृत किया है कर्ल पुस्तकालय, और निरंतर संदेश (जो चहचहाना बाकी एपीआई परीक्षण पर पकड़े गए थे)

• अतिरिक्त सामान नहीं ठीक transfer.c: 1037: 0 0

मेरी नई-नई अद्यतन कर्ल --version डेटा

$ कर्ल गायब हो गए हैं -वी

कर्ल 7.38.0 (x86_64-पीसी-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.3 librtmp/2.3 प्रोटोकॉल: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp विशेषताएं: AsynchDNS IDN IPv6 Largefile जीएसएस-एपीआई एसपीएनईजीओ एनटीएलएम एनटीएलएम_डब्ल्यूबी एसएसएल libz टीएलएस-एसआरपी