2012-11-15 17 views
9

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

जहां तक ​​मैं यह कह सकता हूं कि सर्वर पर POST अनुरोध भेजने के लिए XMLHttpRequest का उपयोग करके किसी भी एप्लिकेशन के साथ होगा, अगर अनुरोध गलत पल पर भेजा जाता है। मैंने एक नमूना कार्यक्रम लिखा है जो केवल उन समय POSTS भेजने का प्रयास करता है। यह सर्वर को कनेक्शन को बंद करने के सटीक पल पर सर्वर पर निरंतर POSTs भेजने का प्रयास करता है। अंतराल सर्वर द्वारा भेजे गए Keep-Alive शीर्षलेख से लिया गया है।

मुझे लगता है कि आईई से थोड़ी देर के विलंब के साथ सर्वर पर चलने पर (यानी एक ही लैन पर नहीं), समस्या केवल कुछ पोस्ट के बाद होती है। जब ऐसा होता है, तो आईई इतनी मेहनत कर देता है कि इसे बल बंद करना होगा। टिकिंग घड़ी एक संकेत है कि ब्राउज़र अभी भी प्रतिक्रिया दे रहा है।

आप इसे ब्राउज़ करके इसे आजमा सकते हैं: http://pubdev.hitech.com/test.post.phpकृपया ध्यान रखें कि आपके द्वारा चलाए जाने पर किसी भी आईई सत्र में आपके पास कोई भी महत्वपूर्ण सहेजी गई जानकारी नहीं है, क्योंकि मुझे लगता है कि यह आईई को क्रैश करेगा।

पूर्ण स्रोत को पुनर्प्राप्त किया जा सकता है: http://pubdev.hitech.com/test.post.php.txt। आप इसे किसी भी सर्वर पर चला सकते हैं जिसमें php है और लगातार कनेक्शन के लिए कॉन्फ़िगर किया गया है।

मेरे प्रश्न हैं:

  1. इस मुद्दे के साथ अन्य लोगों के अनुभवों को क्या हैं?

  2. क्या इस समस्या के आसपास काम करने के लिए कोई ज्ञात रणनीति है ("किसी अन्य ब्राउज़र का उपयोग करें")?

  3. क्या माइक्रोसॉफ्ट के पास इस आलेख के बारे में बेहतर जानकारी है जो मैंने पाया है (नीचे देखें)?

समस्या यह है कि वेब ब्राउज़र और डिफ़ॉल्ट उपयोग लगातार कनेक्शन द्वारा सर्वर (http://www.ietf.org/rfc/rfc2616.txt देखें) RFC 2616 खंड 8.1 में वर्णित है। यह प्रदर्शन के लिए बहुत महत्वपूर्ण है - खासकर AJAX अनुप्रयोगों के लिए - और इसे अक्षम नहीं किया जाना चाहिए। हालांकि एक छोटा समय छेद है जहां ब्राउज़र पहले से इस्तेमाल किए गए कनेक्शन पर एक पोस्ट भेजने शुरू कर सकता है, साथ ही सर्वर कनेक्शन को निष्क्रिय करता है और इसे बंद करने का निर्णय लेता है। नतीजा यह है कि ब्राउज़र के HTTP स्टैक को सॉकेट त्रुटि मिलेगी क्योंकि यह बंद सॉकेट का उपयोग कर रही है। आरएफसी 2616 सेक्शन 8.1.4 इस स्थिति की उम्मीद करता है, और कहता है, "... क्लाइंट, सर्वर, और प्रॉक्सी असीमित बंद घटनाओं से पुनर्प्राप्त करने में सक्षम होना चाहिए। क्लाइंट सॉफ़्टवेयर को परिवहन कनेक्शन को फिर से खोलना चाहिए और उपयोगकर्ता इंटरैक्शन के बिना अनुरोधों के निरस्त अनुक्रम को पुनः प्रेषित करना चाहिए ... "

इंटरनेट एक्सप्लोरर ऐसा होता है जब पोस्ट होता है, लेकिन जब यह अनुरोध को उलझता है। यह पोस्ट हेडर भेजता है, जिसमें पोस्ट की गई डेटा की सामग्री-लंबाई शामिल है, लेकिन यह डेटा नहीं भेजता है। यह एक अनुचित अनुरोध है, और सर्वर त्रुटि के अनुरोध में विफल होने से पहले वादा किए गए डेटा के लिए अनिर्दिष्ट समय का इंतजार करेगा। मैं इस विफलता को एक सी प्रोग्राम का उपयोग करके 100% समय का प्रदर्शन करने में सक्षम हूं जो HTTP सर्वर को अनुकरण करता है, जो प्रतिक्रिया भेजने के बिना किसी आने वाले POST अनुरोध की सॉकेट को बंद करता है।

माइक्रोसॉफ्ट http://support.microsoft.com/kb/895954 में इस विफलता को स्वीकार करता है। वे कहते हैं कि यह आईई संस्करण प्रभावित करता है 9. यही कारण है कि इस समस्या यह है कि IE के सभी संस्करणों के साथ आईई 7 के बाद से भेज दिया गया है के लिए एक हॉटफिक्स उपलब्ध कराने हॉटफिक्स निम्नलिखित कारणों के लिए संतोषजनक नहीं लगता है के माध्यम से 6:

  1. यह तब तक सक्षम नहीं है जब तक आप रजिस्ट्री में FEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954 नामक कुंजी जोड़ने के लिए regedit का उपयोग न करें। यह ऐसा कुछ नहीं है जिसे मैं अपने उपयोगकर्ताओं को करना चाहता हूं।

  2. हॉटफिक्स वास्तव में टूटी हुई पोस्ट को ठीक नहीं करता है। इसके बजाए, अगर आरएफसी द्वारा अनुमानित सॉकेट बंद हो जाता है, तो यह पोस्ट को नाराज करने की कोशिश किए बिना तुरंत त्रुटिपूर्ण हो जाता है। एप्लिकेशन अभी भी विफल रहता है - यह जल्द ही विफल हो जाता है।

निम्नलिखित उदाहरण एक स्वयं निहित PHP प्रोग्राम है जो बग को प्रदर्शित करता है। यह सर्वर को कनेक्शन को बंद करने के सटीक पल पर सर्वर पर निरंतर POSTs भेजने का प्रयास करता है। अंतराल सर्वर द्वारा भेजे गए Keep-Alive शीर्षलेख से लिया गया है।

+0

क्या आपने कभी इस के आसपास एक रास्ता खोजा है? मैं jQuery AJAX पोस्ट ऑपरेशंस का उपयोग कर एक ही समस्या का सामना कर रहा हूँ। – ClearCloud8

+0

@ टोनी-एबो मैं इसी तरह की समस्या में भाग रहा हूं। जानना उत्सुक है कि इसके लिए कोई फिक्स है या नहीं? जीईटी अनुरोध के लिए ऐसा क्यों नहीं होता है? क्या ऐसा इसलिए है क्योंकि जीईटी में कोई शरीर नहीं है और इसलिए नेटवर्क विफलता पर पुनर्वित्त सफल है? –

उत्तर

0

नहीं, आम तौर पर आईई में POST काम करता है। यह एक मुद्दा हो सकता है, आप क्या कह रहे हैं, लेकिन इस विशाल पोस्ट के लायक होने के लिए यह इतना बड़ा मुद्दा नहीं है।

और जब आप पोस्ट AJAX अनुरोध जारी करते हैं, यह सुनिश्चित करने के लिए कि प्रत्येक ब्राउज़र असंगतता कवर हो, बस jquery का उपयोग करें।

एक और बात: नूने समझदार "अन्य ब्राउज़र का इस्तेमाल करने के लिए" क्योंकि आईई व्यापक रूप से प्रयोग किया जाता है आपको बता और का ख्याल रखा जाना चाहिए होगा (अच्छी तरह से, IE6 को छोड़कर और कुछ के लिए, हो सकता है यहां तक ​​कि कुछ नए संस्करणों)

तो, पोस्ट में आईई में काम करने के लिए है, लेकिन खुद को अप्रत्याशित छोटी गाड़ी व्यवहार के लिए कवर करने के लिए, jquery का उपयोग करें और आप अच्छी तरह सो सकते हैं।

+3

यह वास्तव में हो रहा है। जब मैं intermittent कहता हूं, मेरा मतलब सर्वर के आधार पर POSTs के 1% से 10% से कहीं भी है। आप कैसे कह सकते हैं कि यह कोई बड़ा मुद्दा नहीं है? इससे कोई फ़र्क नहीं पड़ता कि आप किस जावास्क्रिप्ट लाइब्रेरी का उपयोग करते हैं क्योंकि समस्या HTTP स्टैक में है। आपको पोस्ट से एक त्रुटि वापस मिल जाएगी। तब आप क्या करते हो? –

0

मुझे इस मुद्दे का कभी सामना नहीं हुआ है। और हमारे ग्राहक ज्यादातर आईई 6 चलाते हैं।

मुझे संदेह है कि आपने अपना रख-रखाव टाइमर बहुत लंबा कॉन्फ़िगर किया है। अधिकांश लोग इसे 1 सेकंड से कम करने के लिए कॉन्फ़िगर करते हैं क्योंकि लगातार कनेक्शन केवल पेज लोडिंग को गति देने के लिए होता है, न कि सेवा अजाक्स कॉल।

यदि आपके पास जीवित-रखें बहुत लंबा आप दुर्घटनाग्रस्त IE की तुलना में अधिक गंभीर समस्याओं का सामना करेंगे कॉन्फ़िगर किया गया - अपने सर्वर फ़ाइल वर्णनकर्ता बाहर चलेंगे सॉकेट खोलने के लिए *

* टिप्पणी: संयोग से, उद्घाटन और नहीं HTTP सर्वर से कनेक्शन बंद करना एक प्रसिद्ध डॉस हमला है जो सर्वर को अपनी अधिकतम खुली सॉकेट सीमा तक पहुंचने के लिए मजबूर करने का प्रयास करता है। यही कारण है कि अधिकतर सर्वर प्रशासक बहुत लंबे समय तक सॉकेट खोलने से बचने के लिए कनेक्शन टाइमआउट को कॉन्फ़िगर करते हैं।

+0

आपके उत्तर के लिए धन्यवाद। कुछ विचार: –

+0

अपाचे 2.2 में अपाचे 2.0 से 5 सेकंड में रख-रखाव डिफ़ॉल्ट 15 सेकंड से बदल दिया गया है। मैंने उन्हें अपने आवेदन चलाने वाले सर्वरों पर स्पष्ट रूप से नहीं बदला है। ऐसा लगता है कि यह समस्या किसी भी जीवित टाइमआउट सेटिंग के साथ होती है, जब तक कि कनेक्शन बंद होने के समय अगला अनुरोध होता है। यह सुनिश्चित करने का एकमात्र तरीका यह कभी नहीं होता है कि लगातार कनेक्शन लगातार अक्षम हो जाएंगे। –

+0

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

6

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

ध्यान रखें कि सर्वर पर रखरखाव में वृद्धि का मतलब है कि एक निष्क्रिय कनेक्शन सर्वर सॉकेट का उपयोग कर रहा है। तो आपको बड़ी संख्या में निष्क्रिय निष्क्रिय कनेक्शन को संभालने के लिए सर्वर को आकार देने की आवश्यकता हो सकती है। यह एक समस्या हो सकती है क्योंकि इसके परिणामस्वरूप सर्वर को लोड का विस्फोट हो सकता है कि सर्वर संभाल नहीं पा रहा है।

ध्यान में रखने के लिए एक और बात। आप ध्यान दें कि आरएफसी अनुभाग 8.1.4 कहता है: "... क्लाइंट, सर्वर, और प्रॉक्सी असीमित बंद घटनाओं से पुनर्प्राप्त करने में सक्षम होना चाहिए। क्लाइंट सॉफ़्टवेयर को परिवहन कनेक्शन को फिर से खोलना चाहिए और बिना उपयोगकर्ता इंटरैक्शन के अनुरोधों के निरस्त अनुक्रम को पुनः प्रेषित करना चाहिए .. "

आप एक बहुत ही महत्वपूर्ण हिस्सा भूल गए। यहां पूरा पाठ दिया गया है: क्लाइंट सॉफ़्टवेयर को परिवहन कनेक्शन को दोबारा खोलना चाहिए और अनुरोधों के निरंतर अनुक्रम को फिर से प्रेषित करना चाहिए जब तक उपयोगकर्ता अनुक्रम के बिना अनुरोध अनुक्रम idempotent (अनुभाग 9.1.2 देखें)। गैर-idempotent विधियों या अनुक्रम स्वचालित रूप से पुनः प्रयास नहीं किया जाना चाहिए, हालांकि उपयोगकर्ता एजेंट मानव ऑपरेटर अनुरोध (अनुरोधों) को पुनः प्रयास करने का विकल्प प्रदान कर सकते हैं। उपयोगकर्ता की पुष्टि के लिए आवेदन मई विकल्प की अर्थपूर्ण समझ के साथ उपयोगकर्ता-एजेंट सॉफ़्टवेयर द्वारा पुष्टि। स्वत: पुनः प्रयास दोहराया जाना चाहिए यदि अनुरोधों का दूसरा अनुक्रम

एक HTTP पोस्ट 9.1.2 द्वारा परिभाषित गैर-idempotent है। इस प्रकार रजिस्ट्री हैक का व्यवहार वास्तव में आरएफसी प्रति तकनीकी रूप से सही है।

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^