علامة HTTP ETag

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

علامة ETag هي مُعرّف غير شفاف يُخصصه خادم الويب لإصدار مُحدد من مورد موجود على عنوان URL . ^{[ 2 ]} إذا تغير تمثيل المورد على عنوان URL هذا، يتم تخصيص علامة ETag جديدة ومختلفة. عند استخدامها بهذه الطريقة، تُشبه علامات ETag بصمات الأصابع ، ويمكن مقارنتها بسرعة لتحديد ما إذا كان تمثيلان للمورد متطابقين.

يُعدّ استخدام علامات ETag في ترويسة HTTP اختياريًا (وليس إلزاميًا كما هو الحال مع بعض الحقول الأخرى في ترويسة HTTP 1.1). ولم تُحدد طريقة توليد علامات ETag في مواصفات HTTP.

تشمل الطرق الشائعة لإنشاء ETag استخدام دالة تجزئة مقاومة للتصادم لمحتوى المورد، أو تجزئة الطابع الزمني لآخر تعديل، أو حتى مجرد رقم مراجعة .

لتجنب استخدام بيانات ذاكرة التخزين المؤقت القديمة، ينبغي أن تضمن الطرق المستخدمة لإنشاء علامات ETag (قدر الإمكان) أن تكون كل علامة ETag فريدة. ومع ذلك، يمكن اعتبار دالة إنشاء علامات ETag "قابلة للاستخدام" إذا أمكن إثبات (رياضيًا) أن تكرار علامات ETag سيكون "نادرًا بشكل مقبول"، حتى لو كان من الممكن أو المتوقع حدوثه.

تنص RFC-7232 صراحةً على أن علامات ETag يجب أن تكون على دراية بترميز المحتوى ، على سبيل المثال

ETag: "123-a" – لعدم وجود ترميز للمحتوى ETag: "123-b" – لتشفير المحتوى: gzip

من المعروف أن بعض دوال التحقق من المجموع الاختباري السابقة ، التي كانت أضعف من CRC32 أو CRC64، تعاني من مشاكل تصادم التجزئة. ولذلك، لم تكن مرشحة جيدة للاستخدام في توليد علامات ETag.

تدعم آلية ETag كلاً من التحقق القوي والتحقق الضعيف . ويتم التمييز بينهما من خلال وجود الحرف "W/" في بداية مُعرّف ETag، كما يلي:

"123456789" – مُدقِّق قوي لعلامات ETag W/"123456789" – مدقق ETag ضعيف

يشير تطابق ETag القوي إلى أن محتوى تمثيلي الموارد متطابق تمامًا، وأن جميع حقول الكيان الأخرى (مثل Content-Language) لم تتغير أيضًا. تسمح علامات ETag القوية بتخزين الاستجابات الجزئية وإعادة تجميعها، كما هو الحال مع طلبات نطاق البايتات .

يشير تطابق ETag ضعيف التحقق إلى أن التمثيلين متكافئان دلاليًا ، ما يعني أنهما عمليًا قابلان للتبادل ويمكن استخدام النسخ المخزنة مؤقتًا. مع ذلك، لا يتطابق تمثيلا الموارد بالضرورة بايتًا ببايت، وبالتالي فإن ETag الضعيف غير مناسب لطلبات نطاق البايتات. قد يكون ETag الضعيف مفيدًا في الحالات التي يكون فيها توليد ETag القوي غير عملي لخادم الويب، كما هو الحال مع المحتوى المُنشأ ديناميكيًا .

في الاستخدام المعتاد، عند استرداد عنوان URL، يقوم خادم الويب بإرجاع التمثيل الحالي للمورد بالإضافة إلى قيمة ETag المقابلة له، والتي يتم وضعها في حقل "ETag" في رأس استجابة HTTP:

ETag: "686897696a7c876b7e"

قد يقرر العميل بعد ذلك تخزين التمثيل مؤقتًا، بالإضافة إلى علامة ETag الخاصة به. لاحقًا، إذا أراد العميل استرداد نفس مورد عنوان URL مرة أخرى، فسيتحقق أولًا مما إذا كانت النسخة المخزنة محليًا من عنوان URL قد انتهت صلاحيتها (عبر رأسي Cache-Control وExpire). إذا لم تنتهِ صلاحية عنوان URL، فسيسترد المورد المخزن محليًا. أما إذا تبين أن عنوان URL قد انتهت صلاحيته (أي أنه قديم )، فسيرسل العميل طلبًا إلى الخادم يتضمن نسخته المحفوظة مسبقًا من علامة ETag في حقل "If-None-Match". ^{[ 2 ]}

إذا لم يكن هناك تطابق: "686897696a7c876b7e"

في هذا الطلب اللاحق، قد يقارن الخادم قيمة ETag الخاصة بالعميل مع قيمة ETag الخاصة بالإصدار الحالي للمورد. إذا تطابقت قيم ETag، أي أن المورد لم يتغير، فقد يرسل الخادم استجابة قصيرة جدًا مع رمز حالة HTTP 304 (غير معدل) . يشير رمز الحالة 304 إلى أن الإصدار المخزن مؤقتًا لدى العميل لا يزال صالحًا، وأنه ينبغي عليه استخدامه.

مع ذلك، إذا لم تتطابق قيم ETag، مما يعني أن المورد قد تغير على الأرجح، فسيتم إرجاع استجابة كاملة تتضمن محتوى المورد، تمامًا كما لو لم يتم استخدام ETags. في هذه الحالة، قد يقرر العميل استبدال النسخة المخزنة مؤقتًا سابقًا بالتمثيل المُعاد حديثًا للمورد وقيمة ETag الجديدة.

يمكن استخدام قيم ETag في أنظمة مراقبة صفحات الويب . إلا أن كفاءة هذه المراقبة تعيقها حقيقة أن معظم المواقع الإلكترونية لا تُفعّل رؤوس ETag لصفحاتها. فعندما لا يتوفر لدى نظام مراقبة الويب أي مؤشرات حول تغيير محتوى الموقع، يصبح من الضروري استرجاع جميع المحتويات وتحليلها، مما يُهدر موارد حاسوبية على كلٍ من الناشر والمستخدم.

يمكن استخدام علامات ETag لتتبع المستخدمين الفريدين، ^{[ 4 ]} حيث يقوم المستخدمون المهتمون بالخصوصية بحذف ملفات تعريف الارتباط HTTP بشكل متزايد. في يوليو 2011، أفاد أشكان سلطاني وفريق من الباحثين في جامعة كاليفورنيا في بيركلي أن عددًا من المواقع الإلكترونية، بما في ذلك Hulu ، كانت تستخدم علامات ETag لأغراض التتبع. ^{[ 5 ]} توقفت كل من Hulu وKISSmetrics عن إعادة إنشاء هذه العلامات اعتبارًا من 29 يوليو 2011، ^{[ 6 ]} حيث تواجه KISSmetrics وأكثر من 20 من عملائها دعوى قضائية جماعية بسبب استخدام ملفات تعريف ارتباط التتبع "غير القابلة للحذف" والتي تتضمن جزئيًا استخدام علامات ETag. ^{[ 7 ]}

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

قد يكون من الممكن مسح علامات ETag عن طريق مسح ذاكرة التخزين المؤقت للمتصفح (تختلف التطبيقات).

• وثائق خادم Apache HTTP – توجيه FileETag
• تحرير الويب: اكتشاف مشكلة التحديث المفقود باستخدام عملية السحب غير المحجوزة ، ملاحظة W3C، 10 مايو 1999.
• عرض توضيحي مباشر لملف تعريف الارتباط الزومبي باستخدام علامات ETag
• مشاريع تطوير SQUID القديمة – دعم ETag مؤرشفة في 23 سبتمبر 2012 على Wayback Machine (اكتملت في عام 2001)
• استخدام علامات ETag لتقليل عرض النطاق الترددي وحمل العمل مع Spring و Hibernate
• ETag في مواصفات HTTP/1.1
• كتاب "حول علامات Etags والطوابع الزمنية" بقلم لارس ر. كلاوسن (2004)