فاحص ETag

ما ETag، وما معنى الـW/؟

الـETag سلسلة معتمة يلحقها الخادم بنسخة من مورد. يحفظها العميل ويعيدها في الطلب التالي، فيسع الخادم أن يجيب بـ304 بدل الجسم كله إن لم يتغير شيء. وللقيمة قواعد صغيرة: بادئة W/ اختيارية، ثم الوسم بين علامتي اقتباس مزدوجتين لا بد منهما.

والعلامتان جزء من القيمة لا زينة، والمحارف المسموحة أضيق مما يظن الناس: المجموعة هي ‎%x21‎ ومن ‎%x23‎ إلى ‎%x7E‎، وهي تستثني علامة الاقتباس المزدوجة، وتستثني المسافة كذلك وهو الأقل بداهةً. أما الشرطة المائلة العكسية فمقبولة، وإن كانت المواصفة تنصح بتجنبها لأن المتلقين القدامى قد يحاولون فكّ تهريبها.

وبادئة W/ تعني أن الوسم مدقّق ضعيف. والشرح المعتاد أن الوسم الضعيف يعرّف نسخةً مكافئة في المعنى لا مطابقةً بايتًا ببايت، وذلك صحيح ويجعله يبدو ملاحظةً صغيرة عن الدقة. وليس كذلك: بل يغيّر ما يصلح له الوسم أصلًا.

كيفية الاستخدام

1. ضع ETag الخادم في الحقل الأول. كما يظهر في ترويسة الرد تمامًا، بعلامتي الاقتباس وبادئة W/ إن وُجدت. وما كان مختلَّ البنية يُشرح لا يُهمَل صامتًا.
2. وضع في الثاني الوسم الذي يُقارَن به. وهو في العادة ما يرسله العميل في If-None-Match أو في If-Match.
3. اقرأ نتيجتي المقارنة ثم جدول الترويسات. فحين تختلف الدالتان يتوقف الجواب كليًا على أي ترويسة تسأل، والجدول أدناه يفصّل ما تفعله كل واحدة.

دالتا مقارنة، وواحدة لا يذكرها أحد

ليس في HTTP دالةُ مقارنة واحدة لوسوم الكيان، بل اثنتان، ويشترط في كل موضع غير ما يشترط في الآخر. فالقسم 13.1.2 من RFC 9110 يقول إن على المتلقي أن يستعمل المقارنة الضعيفة لـIf-None-Match. والقسم 13.1.1 يقول إن على خادم المنشأ أن يستعمل المقارنة القوية لـIf-Match.

والمقارنة الضعيفة تتجاهل بادئة W/ تجاهلًا تامًا وتقارن الوسمين المعتمين. أما القوية فتشترط تساويهما وأن يكونا قويين معًا. والنتيجة هي ما يجدر حمله: الـETag الضعيف لا يفي بالمقارنة القوية أبدًا، ولا حتى في مواجهة نسخة مطابقة من نفسه. وتطبع المواصفة ذلك في جدولها هي: فـW/"1" مقابل W/"1" متطابقان بالمقارنة الضعيفة وغير متطابقين بالقوية.

فالـETag الضعيف إذن يُخزَّن مؤقتًا خير تخزين ولا يقبل الكتابة عليه. وكل PUT أو PATCH شرطي يستعمل If-Match للتزامن التفاؤلي يفشل دائمًا، مهما أرسل العميل. ولا خطأ يشرح ذلك، بل الشرط لا يتحقق قط. فإن كانت واجهتك تعيد 412 عند كل تحديث وكان الـETag يبدأ بـW/، فهذا هو السبب.

وليست هذه إعدادات نادرة. فعلى أكثر 250 نطاقًا زيارةً، وقد أجاب منها 173، لا يرسل ETag إلا 20.2%، ومن هؤلاء 25.7% ضعيفة، منها wikipedia.org وgithub.com وapache.org. وهو للصفحة المخزَّنة اختيار سديد، لأن الوسم الضعيف ينجو من الضغط وسائر التحويلات التي تغيّر البايتات دون المعنى. أما لنقطة واجهة برمجية يحدّثها الناس فهو يحذف ميزةً لا يدري أحد أنه فقدها.

وIf-Range ثالثة الحالات وتعمل على نحو آخر: فالقيد فيها على العميل، إذ يقول القسم 13.1.5 إنه لا يجوز للعميل أن يولّد ترويسة If-Range فيها وسم ضعيف، فاستئناف التنزيل الجزئي يقتضي مدقّقًا قويًا بحكم البناء لا بحكم المقارنة.

حدود صريحة، وكيف جرى التحقق

هذا يقارن وسمين تلصقهما أنت، ولا يرسل أي طلب، فلا يسعه أن يخبرك بما يرسله خادمك: فالمتصفح لا يقرأ ترويسات رد اعتباطية من أصل آخر، وأي أداة تدّعي غير ذلك فهي تمرّر الطلب عبر خادم. وأدوات المطوّر في متصفحك تعرض لك الترويسة بنقرة، وتلك هي الطريقة الصحيحة.

وأمرٌ لا تدّعيه هذه الصفحة عمدًا: أن الخوادم تصدر عادةً ETags مختلّة القواعد. كان ذلك نصف الفكرة الثاني، فقتله القياس. فلا واحد من الـ35 وسمًا حقيقيًا في العينة كان مختلًّا. فهذه الترويسة تصدرها الأطر البرمجية، ولا يكاد أحد يكتب واحدةً بيده. ولا يزال الفاحص يشرح المدخل المختل، لأن من كتبه يستحق جوابًا، لكنه ليس الحقيقة المهمة ولا تتظاهر الصفحة بذلك.

ومنطق المقارنة مقابَل بجدول المواصفة نفسها ذي الصفوف الأربعة، يُستخرج من نص الـRFC في كل تشغيل للاختبارات بدل نسخه، فلا ينجو خطأ نقل. وفيه 513 تحققًا و14 ضابطًا سالبًا. وقد تبيّن أن اثنتين من حالاتي الاختبارية تحملان افتراضاتي لا القواعد: فقد عددتُ وسمًا فيه مسافة صحيحًا، وآخر فيه شرطة مائلة عكسية خاطئًا، والقواعد تقول العكس في الحالين.

لماذا هي مجانية؟

هذه مقارنة سلاسل، تجري في متصفحك، فلا خادم يُدفع ثمنه ولا تسجيل يُطلب.

وما تكتبه لا يُرفع ولا يُخزَّن ولا يُسجَّل. فوسوم ETag معتمة بحكم تصميمها، وقد ترمّز أحيانًا عن المورد أكثر مما أراد مُصدِرها، فيحسن القول إنها تبقى في اللسان.