101 Switching Protocols का मतलब है कि सर्वर क्लाइंट का Upgrade रिक्वेस्ट हेडर स्वीकार करता है। 101 रिस्पॉन्स को खत्म करने वाली खाली लाइन के ठीक बाद दोनों पक्ष इस कनेक्शन पर एक अलग प्रोटोकॉल में बात करने लगते हैं। रिस्पॉन्स में एक Upgrade हेडर होना ज़रूरी है, जो नए प्रोटोकॉल का नाम बताता है।
आजकल यह लगभग हमेशा WebSocket हैंडशेक होता है। ब्राउज़र Upgrade: websocket, Connection: Upgrade और एक Sec-WebSocket-Key के साथ GET भेजता है। सर्वर मेल खाते Sec-WebSocket-Accept के साथ 101 लौटाता है, और उसके बाद दोनों पक्ष WebSocket फ़्रेम का लेन-देन करते हैं। 101 का इस्तेमाल सादे (cleartext) HTTP/1.1 से HTTP/2 पर h2c अपग्रेड के लिए भी होता था, जो अब डेप्रिकेटेड है। अब ब्राउज़र इसकी जगह TLS हैंडशेक के दौरान (ALPN से) HTTP/2 और HTTP/3 तय करते हैं।
Upgrade की व्यवस्था सिर्फ़ HTTP/1.1 में है। HTTP/2 और HTTP/3 कभी 101 नहीं भेजते; इन प्रोटोकॉल पर WebSocket एक्सटेंडेड CONNECT (RFC 8441 और RFC 9220) का इस्तेमाल करते हैं।
उदाहरण रिस्पॉन्स
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO और रीडायरेक्ट जांच
101 कभी भी किसी सामान्य पेज रिक्वेस्ट का नतीजा नहीं होता। ब्राउज़र और क्रॉलर को यह तभी मिलता है जब वे साफ़ तौर पर कनेक्शन अपग्रेड करने को कहते हैं, इसलिए इंडेक्सिंग पर इसका कोई असर नहीं होता। रीडायरेक्ट चेकर सादी GET, HEAD या POST रिक्वेस्ट भेजता है, इसलिए उसे 101 नहीं दिखेगा। अगर किसी WebSocket एंडपॉइंट को सामान्य URL की तरह जांचा जाए, तो वह आम तौर पर 426 Upgrade Required या 400 Bad Request जैसा कोई 4xx कोड लौटाता है।
आम वजहें और इस्तेमाल
- ब्राउज़र एक WebSocket (
new WebSocket('wss://...')) खोलता है और सर्वर हैंडशेक स्वीकार कर लेता है। - कोई क्लाइंट सादे HTTP/2 के लिए डेप्रिकेटेड
h2cअपग्रेड मांगता है और सर्वर उसे सपोर्ट करता है। - रिवर्स प्रॉक्सी के पीछे WebSocket काम नहीं करते, क्योंकि प्रॉक्सी
UpgradeऔरConnectionहेडर आगे नहीं भेजता। nginx मेंproxy_http_version 1.1सेट करें और दोनों हेडर बैकएंड तक पहुंचाएं।