2012-04-16 27 views
9

का उपयोग करके जीईटी से प्रतिक्रिया दें मैंने आरईएसटी सर्वर विधि कॉल निष्पादित करने के लिए अपने आईओएस प्रोजेक्ट में ASIHTTPRequest का उपयोग करना शुरू कर दिया है और अब तक इसके साथ बहुत सफल रहा है। मैं सिर्फ एक अजीब intermittent समस्या है।उद्देश्य सी - HTTP/0.9 प्रतिक्रिया ASIHTTPRequest

HTTP/0.9 200 ठीक

जब यह अपने सर्वर विधि होता है कहा जाता है नहीं प्राप्त करता है: बहुत कभी कभी मैं [ASIHTTPRequest startAsynchronous] का उपयोग करने से निम्नलिखित प्रतिक्रिया मिल। आम तौर पर प्रत्येक विधि कॉल 'HTTP/1.1' से शुरू होने वाली प्रतिक्रिया के साथ लौटाता है। मैं कनेक्शन को सुरक्षित करने के लिए एक GeoTrust/RapidSSL प्रमाणपत्र के साथ HTTPS का उपयोग कर रहा हूं। दिलचस्प बात यह है कि मुझे लगता है कि अगर मैं एसएसएल पोर्ट (443) से कनेक्ट करने का प्रयास करता हूं लेकिन प्रोटोकॉल के रूप में 'http' निर्दिष्ट करता हूं तो मुझे वही 'HTTP/0.9 200 ओके' प्रतिक्रिया मिलती है।

बस अधिक जानकारी जोड़ने के लिए - समस्या तब होती है जब ऐप को समय के लिए निष्क्रिय छोड़ दिया जाता है। जैसे अनुरोध सफलतापूर्वक पूर्ण हो जाता है, फिर थोड़ी देर के लिए ऐप निष्क्रिय छोड़ दें, फिर अगले अनुरोध पर समस्या होती है तो ऐप ठीक काम करता रहता है।

क्या कोई भी हो रहा है पर कुछ प्रकाश डाल सकता है?

बहुत धन्यवाद, जोनाथन

अद्यतन: मैं ASIHTTPRequest से कुछ डिबग जानकारी उत्पादन नीचे चिपकाया है जब समस्या उत्पन्न हुई:

2012-07-12 09:35:49.376 mytestapp[3038:18f07] [CONNECTION] Closing connection #13 because it has expired 
2012-07-12 09:35:49.377 mytestapp[3038:18f07] [CONNECTION] Closing connection #14 because it has expired 
2012-07-12 09:35:49.378 mytestapp[3038:18f07] [CONNECTION] Closing connection #15 because it has expired 
2012-07-12 09:35:49.380 mytestapp[3038:18f07] [CONNECTION] Request #39 will use connection #16 
2012-07-12 09:35:49.381 mytestapp[3038:18f07] [CONNECTION] Request #40 will use connection #17 
2012-07-12 09:35:49.382 mytestapp[3038:18f07] [CONNECTION] Request #41 will use connection #18 
2012-07-12 09:35:49.529 mytestapp[3038:18f07] [STATUS] Request <ASIHTTPRequest: 0x88a1e00> finished downloading data (0 bytes) 
2012-07-12 09:35:49.529 mytestapp[3038:18f07] [STATUS] Request <ASIHTTPRequest: 0x88a1e00> received response headers 
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [AUTH] Request <ASIHTTPRequest: 0x88a1e00> has passed Basic authentication 
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [CONNECTION] Got no keep-alive header, will keep this connection open for 60.000000 seconds 
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [CONNECTION] Request #41 finished using connection #18 
2012-07-12 09:35:49.531 mytestapp[3038:18f07] [STATUS] Request finished: <ASIHTTPRequest: 0x88a1e00> 
2012-07-12 09:35:49.531 mytestapp[3038:15803] responseHeaders={ 
} 
2012-07-12 09:35:49.531 mytestapp[3038:18f07] [STATUS] Request cancelled: <ASIHTTPRequest: 0x88a1e00> 
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [STATUS] Request cancelled: <ASIHTTPRequest: 0x88a0200> 
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [STATUS] Request <ASIHTTPRequest: 0x88a0200>: Cancelled 
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [CONNECTION] Request #39 failed and will invalidate connection #16 
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [STATUS] Request cancelled: <ASIHTTPRequest: 0x88a0a00> 
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [STATUS] Request <ASIHTTPRequest: 0x88a0a00>: Cancelled 
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [CONNECTION] Request #40 failed and will invalidate connection #17 
+2

आपका सर्वर पक्ष क्या है? क्या आपने बिल्कुल 100%, स्पष्ट रूप से इनकार किया है कि सर्वर वास्तविक नेटवर्क डेटा स्ट्रीम को वायरसहार्क जैसे पैकेट स्निफ़र के साथ गलत तरीके से जांच कर गलत व्यवहार कर रहा है? – pmdj

+0

कोई भी मौका आपके आईएसपी प्रॉक्सी का उपयोग कर रहा है? – Lefteris

+0

क्या आपने "validatesSecureCertificate = NO;" सेटिंग सेट करने का प्रयास किया है – endy

उत्तर

2

इस मामले में आईओएस बारीकियों के बारे में अनिश्चित लेकिन HTTP 0.9 पूरी तरह से है छोड़ा हुआ। इसके लिए स्पष्ट कारण है - यह "होस्ट:" हेडर का समर्थन नहीं करता है। इसका मतलब है कि एकल आईपी में वर्चुअल होस्ट नहीं हो सकते हैं। 9 0 के अंत में ऐसी चीजें अप्रचलित हो गईं।

ऐसी प्रतिक्रिया वास्तविक जीवन में कभी नहीं होनी चाहिए। यदि यह अभी भी होता है, तो कुछ क्लाइंट ने "GET/HTTP/0.9" जैसे अनुरोध किए। लेकिन ये ग्राहक ~ 15 साल पहले गायब हो गए हैं।

एसएसएल कुछ HTTP है जो ज्यादा जानकारी नहीं है। तो मेरा मानना ​​है कि यह संबंधित नहीं है। एसएसएल सुरंग स्थापित है और उस सादे HTTP के बाद चला गया है।

निष्कर्ष के रूप में मैं आपको कहूंगा या किसी ने संभवतः अप्रचलित विधि को ट्रिगर किया होगा। और आईओएस शायद यह नहीं पता कि इसके साथ क्या करना है। शायद आईओएस विधि मेजबान नाम के साथ सीमित विधियों को शामिल किया गया है और इसलिए यह ट्रिगर नहीं करता है। वैसे भी आपको इसके बारे में चिंता नहीं करनी चाहिए यदि ग्राहक वास्तव में 0.9 बोल रहा है क्योंकि इसे किसी भी साइट से उचित उत्तर नहीं मिलते हैं। यदि ग्राहक 1.1 बोल रहा है और आप 0.9 का जवाब देते हैं, तो संभावित रूप से अनुरोध किसी भी तरह गलत तरीके से गलत समझा जाता है और फॉलबैक तंत्र सबसे कम संभव HTTP संस्करण होता है। शायद आप अनुरोध के लिए होस्ट नाम सेट करना भूल गए हैं या इसमें वाक्यविन्यास त्रुटि बनाई है?

1

वेब पर इस समस्या के बारे में कुछ उल्लेख हैं, और मूल रूप से यह लगातार कनेक्शन से संबंधित है, और जब सामग्री-लंबाई शीर्षलेख और कुछ बग़ी सर्वर द्वारा लौटाई गई सामग्री के साथ कुछ गलत होता है। यह ब्राउज़र और आईओएस ढांचे को खराब कर सकता है, और वे वास्तव में हेडर को नोटिस नहीं करते हैं।

यहां one of the possible explanations है।

लगातार कनेक्शन अक्षम करने का प्रयास करें, इसे मदद करनी चाहिए। यह advice ASIHTTPRequest (काफी समान स्थिति) के डेवलपर्स से आया था।

[httpRequest setShouldAttemptPersistentConnection:NO]; 
+0

हाय, प्रतिक्रिया के लिए धन्यवाद। मैंने लगातार कनेक्शन, कुकी दृढ़ता, कीचेन दृढ़ता, सत्र दृढ़ता, कैशिंग इत्यादि को अक्षम करने का प्रयास किया है और समस्या अभी भी हो रही है। –

0

HTTP/0.9 200 OK एक अस्तित्व संदेश संदेश है। HTTP/0।9 को अनुरोध के रूप में परिभाषित किया गया है: GET <Request-URI> HTTP/0.9 <CRLF>, जिस प्रतिक्रिया को [Entity-Body] है, बिना किसी स्थिति रेखा और न ही शीर्षलेख। (< urn: ietf: rfc: 1 9 45 >)

कहीं भी आपके सॉफ़्टवेयर में कोई त्रुटि है। मुझे लगता है कि अनुरोध या तो विफल रहा है, या यह अभी तक प्राप्त नहीं हुआ है।