الخلاصة

  • يعرّف Content-Location المورد المحدد الذي يقابل التمثيل المرفق بالرسالة. ويتغير مدلوله باختلاف الطريقة ورمز الحالة وما إذا كانت قيمته تساوي عنوان الهدف؛ لكنه لا يستبدل الهدف أبداً.
  • يستطيع المتلقي الاستفادة منه لتحديث نسخة محلية أو تمييز نسخة تفاوضية أو استرجاع تقرير حالة لاحقاً. ولا يجوز له أن يستنتج منه إعادة توجيه أو ملكية مرجعية أو إذن كتابة أو طلباً جديداً.

يرسل عميل طلب POST إلى نقطة شراء، فتعود استجابة ناجحة تحمل إيصالاً ومعها Content-Location: /receipts/47. ما الذي قاله الخادم فعلاً؟

قال إن التمثيل المرفق يقابل مورداً يعرّفه /receipts/47، وإن طلب GET إلى ذلك العنوان وقت إنشاء الرسالة كان سيعيد التمثيل نفسه ضمن استجابة 200. لم يطلب من العميل إعادة POST إلى هناك. ولم يحوّل طلب الشراء، ولم يجعل عنوان الإيصال بديلاً مرجعياً لنقطة الشراء، ولم يمنح حق تعديل الإيصال.

هذه الفروق هي جوهر القسم 8.7 من RFC 9110. وهي أيضاً اختبار مفيد لحوكمة البروتوكول: هل يمكن لحقل مشترك أن ينقل معلومة هوية نافعة من دون أن يجمع بصمت سلطة التوجيه والملكية والتصرف؟

يبقى عنوان الهدف هو عنوان الهدف

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

تعرف RFC 9110 حقل Content-Location بأنه مرجع URI يمكن استعماله معرّفاً لمورد محدد يقابل التمثيل المحمول في محتوى الرسالة. وفي لحظة إنشاء الرسالة، كان طلب GET لذلك العنوان سيعيد التمثيل نفسه في استجابة 200. وقد تكون القيمة URI مطلقاً أو مرجعاً جزئياً يحل نسبة إلى URI الهدف.

ثم تأتي قاعدة الحماية: القيمة ليست بديلاً لعنوان الهدف. إنها بيانات وصفية للتمثيل.

يسهل إغفال الفرق لأن القيمتين تبدوان عنوانين. لكن عنوان الهدف يجيب عن سؤال: على أي مورد طبقت هذه الطريقة؟ أما Content-Location فيجيب: إلى أي مورد يقابل المحتوى المحمول؟ تحويل الجواب الثاني إلى الأول يحوّل الوصف إلى أمر.

لحقل Location وظيفة أخرى. فقد يعرّف، تبعاً لرمز الحالة، مورداً أنشئ حديثاً أو يقدم مرجع إعادة توجيه. ويمكن لاستجابة واحدة أن تحمل Location وContent-Location معاً لأن المورد الذي تشير إليه دلالة الحالة قد يختلف عن المورد الذي يمثله جسم الرسالة.

مصفوفة صغيرة أدق من قاعدة عامة

لا توجد دلالة تشغيلية واحدة تقول «اتبع هذا العنوان». يتكون معنى Content-Location من الطريقة والحالة والعلاقة بين عناوين URI. وهذه الحالات المنفصلة هي ما يحفظ الحقل من التمدد الدلالي.

في استجابة 2xx لطلب GET أو HEAD، إذا ساوت القيمة عنوان الهدف، يقول الخادم إن المحتوى تمثيل حالي لذلك المورد في تاريخ إنشاء الرسالة. في GET يؤكد ذلك غالباً ما توقعه المتلقي. وفي HEAD تصف البيانات التمثيل الذي كان سيختار من دون نقل جسمه.

أما إذا جاءت المساواة بعد عملية ناجحة تغير الحالة، مثل PUT أو POST، فالمعلومة أدق: التمثيل المرسل في الاستجابة هو الحالة الجديدة للمورد الهدف. يستطيع المحرر عندئذ تحديث نسخته المحلية من دون GET فوري. ولا يعني هذا أن كل نجاح لطلب POST يحمل المعنى نفسه؛ فالنجاح والمساواة المعلنة جزءان من الدليل.

إذا نجحت الاستجابة واختلف Content-Location عن الهدف، يدعي الخادم الأصلي أن مورداً آخر يقابل التمثيل المحمول. وتضع المواصفة قيداً مهماً: لا يوثق بهذا الادعاء إلا إذا كان المعرّفان يشتركان في مالك المورد، وهو أمر لا يستطيع HTTP تحديده برمجياً وحده. اشتراك الأصل الشبكي أو صحة الشهادة أو تشابه الأسماء لا يثبت الملكية بذاته.

في GET أو HEAD قد توفر القيمة المختلفة معرّفاً أكثر تخصيصاً للنسخة التي اختارها تفاوض المحتوى. يطلب العميل مورداً تفاوضياً، ثم توضح الاستجابة أي مورد يقابل النسخة العربية أو صيغة PDF أو خاصية مختارة أخرى. تفيد المعلومة في الفهرسة وإعادة الاستخدام، لكنها لا تأمر بطلب جديد.

إذا أعادت عملية إنشاء الحالة 201 وكان Content-Location مساوياً لـLocation، فالجسم تمثيل حالي للمورد المنشأ. وإذا اختلفا، حافظ كل حقل على وظيفته: يحدد Location المورد المنشأ، ويحدد Content-Location المورد الذي يقابل الجسم.

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

الادعاء مؤقت وليس وعداً أبدياً

تربط المواصفة التطابق بوقت إنشاء الرسالة. وهذا القيد الزمني يمنع قراءة متضخمة. يقول الخادم الأصلي إن GET كان سيعيد التمثيل نفسه آنذاك. وبعد ذلك قد يتغير المورد أو تنتهي صلاحيته أو يتطلب إذناً آخر أو يختفي.

يمكن للعميل أن يحفظ العلاقة مع تاريخها. لكنه لا ينبغي أن يجمدها حقيقة دائمة. تظل أدوات التحقق وتعليمات التخزين المؤقت وسياسة التطبيق ضرورية. ولا يحول عنوان معرّف المحتوى المتغير إلى كائن ثابت.

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

وجود الحقل في الطلب لا يغير الطلب

قد يظهر Content-Location في طلب أيضاً. يستطيع وكيل المستخدم حينئذ الإبلاغ عن المكان الذي حصل منه أصلاً على المحتوى قبل تعديله. هذه معلومة منشأ عابرة قد تفيد أدوات التأليف.

لكن RFC 9110 تثبت الحد المقابل: لا ينبغي للخادم حفظ هذه المعلومة كما هي بوصفها وصفاً دائماً، ويجب ألا تغير دلالة الطلب. تظل الطريقة موجهة إلى URI الهدف.

لنفترض أن عميلاً تلقى نسخة اختيرت بالتفاوض ثم أراد تعديلها. وضع URI النسخة في Content-Location مع إرسال PUT إلى المورد التفاوضي لا يعيد توجيه PUT. إذا كانت النية تحديث تلك النسخة بالذات، فعلى العميل إرسال الطلب مباشرة إلى URI النسخة. وإلا أصبح حقل وصفي قناة خفية لتوسيع مجال الكتابة.

لهذه القاعدة أثر أمني مباشر. قد يفسر وسيط وبوابة مزامنة والخادم الأصلي «الهدف الموجود داخل البيانات الوصفية» بطرق مختلفة. حين تجبر المواصفة العميل على وضع قصده في هدف الطلب، يبقى مورد العملية ظاهراً لسياسة التفويض وللسجلات وللمراجعة.

إبطال التخزين المؤقت ليس انتقالاً

تضيف RFC 9111 نتيجة قد تسبب التباساً. بعد استجابة غير خاطئة لطريقة غير آمنة، يجب على التخزين المؤقت إبطال الاستجابات المحفوظة لعنوان الهدف. ويمكنه أيضاً إبطال العنوان الذي يشير إليه Location أو Content-Location إذا كان من الأصل نفسه.

لا تمنح هذه القاعدة الحقل سلطة توجيه. إنها احتياط اتساق: ربما جعل تغيير الحالة تمثيلاً مرتبطاً قديماً. أما شرط الأصل الواحد فيمنع استجابة من إبطال محتوى تابع لأصل آخر اعتباطاً.

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

لذلك يجب الفصل بين ثلاث وظائف: ربط الجسم بمورد، وإبطال نسخة يحتمل قدمها، وإطلاق طلب جديد. يشارك Content-Location في الأولى وقد يقدم مرشحاً محدوداً للثانية، لكنه لا ينفذ الثالثة.

سلامة التوقيع لا تنشئ سلطة

تسمح RFC 9421 بتوقيع مكونات رسائل HTTP، ومنها حقول مختارة. يستطيع توقيع صحيح إثبات أن البايتات المغطاة لم تتغير وربطها بالمفتاح المستعمل. لكنه لا يثبت وحده أن صاحب المفتاح يملك عنواني URI، أو أنه مخول بتغيير أحدهما، أو أن على المتلقي تنفيذ فعل.

يفيد ذلك حين يمر Content-Location عبر وسطاء. حماية سلامة القيمة أمر مهم، لكن ملكية المورد والثقة في الخادم الأصلي وإذن القراءة أو الكتابة تظل شؤوناً لنظام الأمن وسياسة التطبيق. يحفظ التشفير الادعاء؛ ولا يوسع مدلوله.

ويقدم سجل IANA الدائم لأسماء حقول HTTP نوعاً مختلفاً من الثبات. فهو يثبت الاسم ويحيل إلى المواصفة المتحكمة. لكنه لا يجعل كل استعمال تاريخي قاعدة راهنة ولا يمنح تأويلات محلية سلطة عامة. تساعد RFC 7231 وRFC 2557 على تتبع تطور الحقل، بينما تظل RFC 9110، الصادرة ضمن Standards Track في يونيو 2022، المرجع المعياري الحالي. ولا تعرض قائمة التصويبات تصويباً مقبولاً يغير حدود القسم 8.7.

تصميم تنفيذي يحفظ الأدوار

يستطيع تصميم جيد تمثيل المعلومة كسجل مستقل يضم URI الهدف وURI المحتوى بعد الحل والطريقة والحالة ووقت الرسالة وعلاقة المساواة والأصل. هذا أفضل من استبدال خاصية عامة اسمها url من دون أثر.

يمكن لطبقة العرض أن توفر خيار «عرض التمثيل المعرّف» عندما يناسب السياق. ويمكن لطبقة التخزين تقييم مرشحي الإبطال وفق RFC 9111. ولا يحدّث المحرر نسخته المحلية إلا في حالة ناجحة ثبت فيها أن عملية تغيير الحالة أعادت قيمة مساوية للهدف. ويبقى نظام التفويض مسؤولاً عن تقييم أي عملية جديدة في وجهتها الفعلية.

ينبغي أيضاً حفظ منشأ الاستنتاج. لا تستحق قيمة من خادم أصلي موثوق وقيمة أعاد وسيط كتابتها وحقل قدمه العميل المعاملة نفسها. حل مرجع نسبي عملية تركيبية؛ أما الثقة في علاقة الموردين فقرار مؤسسي.

يجب أن تختبر البرمجيات المصفوفة لا مجرد قبول المحلل للحقل: GET بقيمة مساوية، وGET تفاوضي بقيمة مختلفة، و201 مع تساوي Location وContent-Location، واستجابة POST تحمل إيصالاً، وقيمة نسبية، ومحاولة عبر أصلين، وPUT يحاول استخدام الحقل لتغيير الهدف. يجب أن توضح النتائج ما يجوز تخزينه أو إبطاله أو عرضه، وما لا يجوز فعله.

الأدلة وحدود المعرفة

المصدر المعياري الرئيس هو RFC 9110. تنظم RFC 3986 حل مراجع URI، وتعالج RFC 9111 إبطال التخزين المؤقت، وتساعد RFC 8288 على تمييز علاقات الروابط ذات الأنواع، وتحدد RFC 9421 ما تثبته توقيعات رسائل HTTP. وتكشف الوثائق التاريخية الاستمرارية، لكنها لا تحل محل المواصفة الحالية. أما سجل IANA فيؤكد الصفة الدائمة للحقل.

تبقى فجوات لا تزيلها طبقة HTTP. فهي لا تستطيع اكتشاف اشتراك معرفين في مالك مورد واحد، ولا تعلم أن العلاقة استمرت بعد زمن الاستجابة. يتطلب ذلك ثقة معدة مسبقاً أو مصادقة أو سياسة تحريرية أو ضوابط تطبيق أو ملاحظة جديدة.

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

المصادر