101 Switching Protocols ومصافحة WebSocket

101 Switching Protocols يعني أن الخادم وافق على طلب العميل تغيير البروتوكول على الاتصال الحالي. بعد الرمز 101 مباشرة، يتوقف الطرفان عن استخدام HTTP/1.1 ويبدآن بالبروتوكول الجديد، وهو في الواقع العملي WebSocket في أغلب الحالات.

كيف تعمل الترقية

يربط RFC 9110، القسم 15.2.2 الرمز 101 بترويسة Upgrade: لا يبدّل الخادم البروتوكول إلا إذا طلب العميل ذلك، ويجب أن يرسل ترويسة Upgrade تسمّي البروتوكول الذي سيتولى الاتصال. ومصافحة WebSocket المعرَّفة في RFC 6455 هي أشهر الأمثلة:

GET /chat HTTP/1.1
Host: app.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

الرمز 101 خاص بـ HTTP/1.1. أما HTTP/2 فقد أسقط دعمه: تُفتح اتصالات WebSocket عبر HTTP/2 بطلب CONNECT موسَّع بدلًا من ذلك (RFC 8441).

لماذا تفشل الترقية

• يحذف البروكسي العكسي (reverse proxy) أو موزّع الأحمال ترويستي Upgrade وConnection لأنهما ترويستان تخصان قفزة واحدة (hop-by-hop)، فيرى التطبيق طلبًا عاديًا ويرد بـ 200 أو 400 بدل 101.
• يغلق البروكسي الاتصالات الخاملة بعد انتهاء مهلة القراءة، فتنقطع المقابس (sockets) الحية.
• لا تسمح شبكة CDN أو باقة الاستضافة باستخدام WebSocket على ذلك النطاق.

إذا كان Nginx أمام تطبيق Node.js أو Python، فمرّر الترويستين صراحةً:

location /ws/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

التأثير على السيو

لا ينطبق الرمز 101 على الصفحة نفسها أبدًا. فالزواحف تطلب HTML بطلبات GET عادية وتحصل على رمز حالة نهائي عادي. الخطر يكمن في المحتوى: النص الذي يصل عبر WebSocket بعد تحميل الصفحة فقط لا يوجد في HTML الصادر من الخادم، وهو ما تقرؤه زواحف كثيرة وأدوات الفحص لدينا. ضع العناوين والنص والروابط في الاستجابة الأولى (راجع JavaScript SEO)، واستخدم المقبس للتحديثات الحية فقط. وتأكد أن رابط الصفحة نفسه يعيد 200 باستخدام أداة فحص حالة HTTP.

الأسئلة الشائعة