सॉकेट.io

Question

से s3_pkt.c में HTTPS त्रुटि "डेटा लंबाई बहुत लंबी" है। हम सॉकेट.ओ फ्लैशस्केट को इंटरनेट एक्सप्लोरर 9 में HTTPS/WSS पर काम करने की कोशिश कर रहे हैं। फ्लैशसाकेट HTTP पर काम करते हैं, लेकिन एचटीटीपीएस हमें समस्याएं दे रहा है। हम socket.io संस्करण 0.8.7 और socket.io-client संस्करण 0.9.1-1 का उपयोग कर रहे हैं।

हम पोर्ट 443 पर SSL के माध्यम से हमारे वेबस्केट सर्वर चला रहे हैं। हमने सही स्थान पर हमारी WebsocketMainInsecure.swf फ़ाइल (ये क्रॉस-डोमेन ws अनुरोध हैं) का स्थान निर्दिष्ट किया है, और हम फ़ाइल लोड कर रहे हैं एचटीटीपीएस पर swfobject एम्बेड में।

हमने अपने ईसी 2 उदाहरण के लिए हमारे सुरक्षा समूह में पोर्ट 843 खोला और क्रॉस मूल नीति फ़ाइल को HTTP पर सफलतापूर्वक प्रस्तुत किया जा रहा है। ऐसा लगता है कि यह HTTPS पर प्रस्तुत नहीं होता है (क्रोम एक एसएसएल कनेक्शन त्रुटि फेंकता है)।

हमने WebsocketMainInsecure.swf फ़ाइल के दो संस्करणों का प्रयास किया है। पहले Socket.io, जो WebsocketMainInsecure.as के बंद बनाया गया है द्वारा प्रदान की फ़ाइल है कि रेखा

Security.allowInsecureDomain("*"); 

यह WebSocket.__flash.setCallerUrl(location.href) त्रुटि पंक्ति SCRIPT16389: Unspecified error. फेंकता शामिल नहीं है।

हम लगा ऐसा इसलिए है क्योंकि SWF फ़ाइल HTTPS अनुरोध की अनुमति नहीं कर रहा था, तो हम भी इस रेपो में पाया साथ WebSocketMainInsecure.swf फ़ाइल की जगह: https://github.com/gimite/web-socket-js क्योंकि यह actionscript में

Security.allowInsecureDomain("*"); 

लाइन भी शामिल है कोड। जब हमने इसका इस्तेमाल किया, हमने देखा कि फ़्लैशस्केट कनेक्शन डिस्कनेक्टिंग और अनंत लूप में पुनः कनेक्ट हो रहा है। हमने ट्रांसपोर्ट प्रोटोटाइप पर onSocketError फ़ंक्शन में socket.io लाइब्रेरी में transport.js फ़ाइल में त्रुटि को ट्रैक किया। यह त्रुटि फेंकता है:

[Error: 139662382290912:error:1408F092:SSL routines:SSL3_GET_RECORD:data length too long:s3_pkt.c:503:] 

हम भी अद्यतन करने की कोशिश की दोनों socket.io और socket.io-क्लाइंट संस्करण 0.9.6 करने के लिए और हम अभी भी Access is denied त्रुटि मिली।

यह त्रुटि डीबग करना बहुत मुश्किल हो गया है, और अब हम फ्लैशस्कॉकेट को काम करने के तरीके के बारे में नुकसान पहुंचा रहे हैं। हम सोच रहे हैं कि इसे socket.io के पुराने संस्करण का उपयोग करने के साथ क्या करना पड़ सकता है, या हो सकता है कि हमारी नीति फ़ाइल सर्वर HTTPS अनुरोधों को स्वीकार नहीं करता है, या यहां तक ​​कि जिस तरीके से WebSocketMainInsecure.swf फ़ाइल वेब- सॉकेट-जेएस जीथब रेपो को सॉकेट.ओ-क्लाइंट की अपेक्षाओं के सापेक्ष बनाया गया था।

Answer 1

मुझे यकीन है कि यह काम नहीं करता है। लेकिन यहाँ मेरा विचार/सुझाव है:

1. विचार: मुझे लगता है कि आप (संभवतः) एक यूआरएल जो बहुत लंबा है का उपयोग करने की कोशिश की। ऐसा तब होता है जब डेटा अक्सर जीईटी-पैरामीटर्स के माध्यम से संचरित होता है। यूआरएल के लिए आधिकारिक सीमा 512 बाइट्स से नीचे है।

विवरण: HTTP विनिर्देश कहता है कि प्रोटोकॉल लाइन अधिकतम 512 बाइट्स पर हो सकती है। यदि लंबा सर्वर अनुरोध को अस्वीकार कर सकता है या अनुरोध को संभालने में असमर्थ हो सकता है। जीईटी-आवश्यकता के साथ HTTP में पहली पंक्ति "GET/path/to? Param1 = data1 & param2 = data2 & ... HTTP/1.1" को 512 बाइट्स में फिट करने की आवश्यकता होगी। POST अनुरोधों के लिए ऐसी कोई सीमा नहीं है ..

हालांकि आपकी त्रुटि कुछ SSL कार्यान्वयन (openSSL?) से उत्पन्न होती है: s3_pkt को refering।लाइन 503 पर सी (मुझे इस तरह की एक फाइल मिली: http://www.opensource.apple.com/source/OpenSSL/OpenSSL-7.1/openssl/ssl/s3_pkt.c) लेकिन यह अलग दिखता है; मुझे ब्योरा नहीं पता है, और मैं अनुमान लगा रहा हूं: मैं सोच सकता हूं कि ओपनएसएसएल कार्यान्वयन में लंबे जीईटी-अनुरोधों के लिए कुछ सीमित समर्थन है (क्योंकि वे HTTP अनुरूप नहीं हैं) और उन्हें इस तरह से अस्वीकार कर देता है ...

मैं अब इन संभावनाओं को देखता हूं: 1. समाधान: लंबे डेटासेट संचारित करने के लिए जीईटी-अनुरोधों के बजाय POST का उपयोग करें। देखें कि यह काम करता है ... 2. उपयोग किए गए सर्वर पर openssl-installation या libopenssl को प्रतिस्थापित करने का प्रयास करें; यह संभवतः टूटा या पुराना है? openssl डेवलपर्स से कुछ मदद का अनुरोध करने के 3. कोशिश ...

आशा है कि मदद करता है ...

Answer 2

कोशिश इमारत (OpenSSL मेलिंग सूची से स्टीवन हेंसन और Jaaron एंडरसन को ऋण) SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER साथ OpenSSL।