वेबसाईट सबप्रोटोकॉल का अनुरोध करते समय HTTP प्रतिक्रिया कोड समर्थित नहीं है/पहचाना

Question

किसी वेबसाईट पर HTTP कनेक्शन को अपग्रेड करते समय, कोई वैकल्पिक HTTP शीर्षलेख 'सेक-वेबसॉकेट-प्रोटोकॉल' में एक या अधिक सबप्रोटोकॉल प्रदान कर सकता है।

यदि सर्वर किसी भी उपप्रोटोकॉल को स्वीकार करता है तो यह HTTP प्रतिक्रिया कोड 101 ("HTTP/1.1 101 स्विचिंग प्रोटोकॉल") के साथ प्रतिक्रिया करता है और चयनित उपप्रॉटोकॉल को इंगित करने वाले HTTP शीर्षलेख 'सेक-वेबसेट-प्रोटोकॉल' शामिल करता है।

लेकिन सर्वर को अज्ञात/असमर्थित उपप्रॉटोकॉल को सही ढंग से कैसे संभालना चाहिए?

क्या यह HTTP कनेक्शन के भीतर 'HTTP' के भीतर किया जाना चाहिए - कुछ HTTP प्रतिक्रिया कोड के उपयोग से?

या कनेक्शन को वेबसाईट में अपग्रेड किया जाना चाहिए - और तुरंत पूर्व निर्धारित वेबसाकेट स्थिति कोड के साथ 'बंद फ्रेम' भेजकर सर्वर द्वारा बंद किया जाना चाहिए?

आरएफसी 6455 क्या कहता है? मैं एक निष्कर्ष पर नहीं आ सकता। मौजूदा सर्वर कार्यान्वयन इसे कैसे संभालता है?

सादर /प्रति/

Answer 1

आरएफसी 6455 पर एक संक्षिप्त झलक से, मेरा मानना ​​है कि WebSocket Subprotocol वैकल्पिक और बातचीत के जरिए है। अनुभाग 4.2.2, के तहत "सर्वर Rquirements" में:

/subprotocol/ 
     Either a single value representing the subprotocol the server 
     is ready to use or null. The value chosen MUST be derived 
     from the client's handshake, specifically by selecting one of 
     the values from the |Sec-WebSocket-Protocol| field that the 
     server is willing to use for this connection (if any). If the 
     client's handshake did not contain such a header field or if 
     the server does not agree to any of the client's requested 
     subprotocols, the only acceptable value is null. The absence 
     of such a field is equivalent to the null value (meaning that 
     if the server does not wish to agree to one of the suggested 
     subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| 
     header field in its response). The empty string is not the 
     same as the null value for these purposes and is not a legal 
     value for this field. The ABNF for the value of this header 
     field is (token), where the definitions of constructs and 
     rules are as given in [RFC2616]. 

सर्वर 'अशक्त' अगर यह ग्राहक के साथ subprotocol उपयोग करने के लिए सहमत नहीं था के अलावा किसी अन्य मूल्य के साथ एक subprotocol प्रतिक्रिया हेडर नहीं भेजना चाहिए, और यह है उस बिंदु पर कनेक्शन जारी रखने या समाप्त करने के लिए ग्राहक की ज़िम्मेदारी।

Answer 2

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

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