مُحيل HTTP

في بروتوكول HTTP ، يُعدّ " Referer " (وهو خطأ إملائي لكلمة " Referrer " ^{[ 1 ]} ) حقلًا اختياريًا في رأس HTTP ، يُحدد عنوان صفحة الويب (أي URI أو IRI ) التي طُلب منها المورد. من خلال فحص المُحيل، يستطيع الخادم الذي يُقدّم صفحة الويب الجديدة معرفة مصدر الطلب.

في الحالة الأكثر شيوعًا، هذا يعني أنه عندما ينقر المستخدم على رابط تشعبي في متصفح الويب ، مما يتسبب في إرسال المتصفح طلبًا إلى الخادم الذي يحتوي على صفحة الويب المقصودة، فقد يتضمن الطلب حقل Referer ، الذي يشير إلى آخر صفحة كان المستخدم عليها (الصفحة التي نقر فيها على الرابط).

تقوم مواقع الويب وخوادمها بتسجيل محتوى حقل "المُحيل" المُستلم لتحديد صفحة الويب التي انتقل منها المستخدم عبر الرابط، وذلك لأغراض ترويجية أو إحصائية. يُؤدي هذا إلى انتهاك خصوصية المستخدم، وقد يُشكّل خطرًا أمنيًا . ^{[ 2 ]} وللحدّ من هذه المخاطر، تعمل المتصفحات باستمرار على تقليل كمية المعلومات المُرسلة في حقل "المُحيل". اعتبارًا من مارس 2021، يقوم متصفح Chrome ^{[ 3 ]} ، ومتصفح Edge المبني على Chromium ، ومتصفح Firefox ^{[ 4 ]} ، ومتصفح Safari ^{[ 5 ]} افتراضيًا بإرسال المصدر فقط في طلبات الوصول من مصادر مختلفة، مُستبعدًا كل شيء عدا اسم النطاق.

أُدخل خطأ إملائي في كلمة "referrer" في الاقتراح الأصلي الذي قدمه عالم الحاسوب فيليب هالام-بيكر لإدراج حقل "Referer" في مواصفات بروتوكول HTTP . ^{[ 6 ] [ 7 ]} وقد ترسخ هذا الخطأ الإملائي بحلول مايو 1996، حين أُدرج في وثيقة معايير طلب التعليقات RFC 1945 ^{[ 8 ]} (التي "تعكس الاستخدام الشائع للبروتوكول المعروف آنذاك باسم 'HTTP/1.0 ' " ). وقد أشار روي فيلدينغ، أحد مؤلفي الوثيقة، في مارس 1995 إلى أن " مدقق الإملاء القياسي لنظام يونكس في تلك الفترة لا يفهم أيًا من الكلمتين ( referer أو referrer)." ^{[ 9 ]} ومنذ ذلك الحين، أصبح استخدام "Referer" شائعًا في هذا المجال عند مناقشة مُحيل HTTP؛ إلا أن استخدام الخطأ الإملائي ليس عالميًا، إذ تُستخدم التهجئة الصحيحة "referrer" في بعض مواصفات الويب، مثل رأس HTTP أو نموذج كائن المستند (DOC) . ^{[ 2 ]}Referrer-Policy

عند زيارة صفحة ويب، يكون المُحيل أو الصفحة المُحيلة هو عنوان URL لصفحة الويب السابقة التي تم اتباع الرابط منها.

بشكل عام، يُشير المُحيل إلى عنوان URL لعنصر سابق أدى إلى هذا الطلب. على سبيل المثال، يكون المُحيل لصورة عادةً هو صفحة HTML التي ستُعرض عليها. يُعد حقل المُحيل جزءًا اختياريًا من طلب HTTP الذي يُرسله متصفح الويب إلى خادم الويب. ^{[ 10 ]}

تسجل العديد من المواقع الإلكترونية عناوين المواقع المُحيلة كجزء من جهودها لتتبع مستخدميها . وتستطيع معظم برامج تحليل سجلات الويب معالجة هذه المعلومات. ولأن معلومات المُحيل قد تنتهك الخصوصية ، تسمح بعض متصفحات الويب للمستخدم بتعطيل إرسالها. ^{[ 11 ]} كما تقوم بعض برامج البروكسي وجدران الحماية بتصفية معلومات المُحيل لتجنب تسريب موقع المواقع غير العامة. وهذا بدوره قد يُسبب مشاكل: إذ تقوم بعض خوادم الويب بحظر أجزاء من مواقعها أمام متصفحات الويب التي لا تُرسل معلومات المُحيل الصحيحة، وذلك في محاولة لمنع الروابط العميقة أو الاستخدام غير المصرح به للصور ( سرقة النطاق الترددي ). وتتمتع بعض برامج البروكسي بالقدرة على إظهار عنوان الموقع المستهدف كمُحيل، مما يُقلل من هذه المشاكل، ولكنه قد يكشف في بعض الحالات عن آخر صفحة زارها المستخدم.

تنشر العديد من المدونات معلومات عن جهات الإحالة بهدف ربطها بالمواقع التي تشير إليها، وبالتالي توسيع نطاق النقاش. وقد أدى ذلك بدوره إلى ظهور ما يُعرف بـ" البريد العشوائي للإحالة" : وهو إرسال معلومات إحالة مزيفة بهدف الترويج لموقع المُرسل.

يمكن الوصول إلى معلومات المُحيل من جانب العميل باستخدام `document.referrer` في جافا سكريبت . ^{[ 12 ]} يُمكن استخدام ذلك، على سبيل المثال، لتخصيص صفحة ويب بناءً على استعلام محرك البحث الخاص بالمستخدم. مع ذلك، لا يتضمن حقل المُحيل دائمًا كلمات البحث، كما هو الحال عند استخدام بحث جوجل مع بروتوكول HTTPS. ^{[ 13 ]}

تحتفظ معظم خوادم الويب بسجلات لجميع عمليات نقل البيانات، وتسجل عنوان URL المُحيل (Referer) الذي يرسله متصفح الويب لكل طلب. يُثير هذا الأمر العديد من المخاوف المتعلقة بالخصوصية، ونتيجةً لذلك، تم تطوير العديد من الأنظمة لمنع إرسال عنوان URL المُحيل الحقيقي إلى خوادم الويب. تعمل هذه الأنظمة إما عن طريق حذف حقل المُحيل أو استبداله ببيانات غير دقيقة. بشكل عام، تقوم برامج أمان الإنترنت بحذف بيانات المُحيل، بينما تستبدلها خوادم الويب بعنوان URL وهمي، عادةً ما يكون عنوانها الخاص. يُثير هذا الأمر مشكلة البريد العشوائي (Spam) الخاص بالمُحيل. تتشابه التفاصيل التقنية لكلا الطريقتين إلى حد كبير - حيث تعمل تطبيقات البرامج كخادم وسيط وتُعالج طلب HTTP، بينما تقوم طرق الويب بتحميل مواقع الويب داخل إطارات، مما يدفع متصفح الويب إلى إرسال عنوان URL مُحيل لعنوان موقع الويب الخاص بها. تُتيح بعض متصفحات الويب لمستخدميها خيار إيقاف تشغيل حقول المُحيل في رأس الطلب. ^{[ 11 ]}

لا تُرسل معظم متصفحات الويب حقل المُحيل عند توجيهها لإعادة التوجيه باستخدام حقل "تحديث". ولا يشمل ذلك بعض إصدارات متصفح أوبرا والعديد من متصفحات الويب على الأجهزة المحمولة. ومع ذلك، فإن اتحاد شبكة الويب العالمية (W3C) لا يُشجع على استخدام هذه الطريقة لإعادة التوجيه . ^{[ 14 ]}

إذا تم الوصول إلى موقع ويب من خلال اتصال HTTPS وكان الرابط يشير إلى أي مكان باستثناء موقع آمن آخر، فلن يتم إرسال حقل المُحيل. ^{[ 10 ]}

أضاف معيار HTML5 دعمًا للخاصية/القيمة rel="noreferrer"، والتي توجه وكيل المستخدم بعدم إرسال المُحيل. ^{[ 15 ]}

تتمثل إحدى طرق إخفاء المُحيل في تحويل رابط URL الأصلي إلى رابط URL قائم على مخطط Data URI ، يحتوي على صفحة HTML صغيرة مع تحديث تلقائي للرابط الأصلي. عند إعادة توجيه المستخدم من data:الصفحة، يتم إخفاء المُحيل الأصلي.

أدخل معيار سياسة أمان المحتوى ( CSP ) الإصدار 1.1 توجيهًا جديدًا للمُحيل ، يتيح مزيدًا من التحكم في سلوك المتصفح فيما يتعلق برأس المُحيل. وبالتحديد، يسمح هذا التوجيه لمدير الموقع بتوجيه المتصفح بعدم حظر المُحيل نهائيًا، أو الكشف عنه فقط عند الانتقال إلى موقع من نفس المصدر، وما إلى ذلك. ^{[ 16 ]}

• RFC 1945 : بروتوكول نقل النص التشعبي -- HTTP/1.0 
• RFC 7231 : بروتوكول نقل النص التشعبي (HTTP/1.1): الدلالات والمحتوى 
• RFC 3987 : معرّفات الموارد الدولية (IRIs) 
• سياسة الإحالة - مسودة محرر W3C