الخلاصة

  • تستطيع خدمة ICAP في نمط REQMOD أن تعيد استجابة خطأ HTTP بدلاً من طلب معدل؛ وقد لا يكون خادم الأصل قد رأى الطلب أصلاً.
  • يجب أن تربط الأدلة كل حالة بمن أنشأها، وبالبايتات التي رآها، وعصر الخدمة المحدد بـ ISTag، ثم تفصل ذلك عن قبول الأصل ونتيجة التطبيق.

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

لم يكن الرمز مزيفاً، لكن نسبته كانت خاطئة. تنسيق HTTP المضمن يصف ما ينبغي أن يستلمه العميل في المرحلة التالية؛ ولا يثبت وحده أن خادم الأصل هو من أصدره.

نشر RFC 3507 في أبريل 2003 بوصفه وثيقة Informational تسجل بروتوكولاً مستخدماً آنذاك. يعمل ICAP كبروتوكول مستقل فوق TCP، ويغلف أجزاء HTTP، لكنه ليس HTTP ولا يعمل فوقه. كما نبهت ملاحظة IESG إلى أنه يسبق قضايا المعمارية والسياسة التي طرحها RFC 3238 بشأن OPES.

REQMOD يستطيع إنهاء المسار قبل الأصل

في تعديل الطلب، ترسل جهة ICAP طلباً HTTP مغلفاً إلى خدمة التكييف. يمكن للخدمة أن تعيد طلباً معدلاً كي يتابع المسار، أو استجابة خطأ HTTP، أو 204 No Content حين تسمح الشروط، أو خطأ على طبقة ICAP.

عندما تعيد الخدمة استجابة HTTP، يكون مصدر الإنشاء هو مسار التكييف. قد يستهلك العميل تلك الاستجابة من دون فتح معاملة مع الأصل. لذلك لا تكفي خانة status code في سجل موحد؛ يلزم اسم الطبقة، وهوية المرسل، واتصال ICAP، وURI الخدمة، ونتيجة الإرسال التالي إن وجد.

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

RESPMOD يصنع فرعاً جديداً من النسب

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

يلزم الاحتفاظ ببصمة قبل التحويل وبعده، وقاعدة التحويل، وهوية الخدمة، والبايتات التي تغيرت، والنتيجة عند المستلم. نجاح ICAP لا يثبت أن المستلم قبل المحتوى أو عرضه أو حقق نتيجة مهنية.

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

المعاينة تحد ما أمكن للخدمة أن تعرفه

يرسل العميل في Preview كل الرؤوس المغلفة وما لا يتجاوز الحجم الذي أعلنته الخدمة من الجسم. ثم يوقف سلسلة chunks مؤقتاً وينتظر قراراً.

يمكن للخدمة أن تعيد نتيجة معدلة، أو 204، أو 100 Continue إذا بقي جزء من الجسم. وقد تقع نقطة الوقف بعد بايتات من الجسم، لا على الحد بين الرؤوس والجسم فقط.

لهذا يجب ربط أي حكم بطول المعاينة المطلوب والفعلي، وإزاحات التغليف، وحدود chunks، وحالة قراءة الأصل وأول بايت لم يصل. الإرشاد التاريخي بدعم 4096 بايت على الأقل ليس عتبة تصنيف عامة.

100 Continue يطلب بقية السؤال

إذا لم ينته الجسم، يسمح 100 Continue للعميل بإرسال ما تبقى بدءاً من أول chunk بعد المعاينة. هذا رد من خدمة ICAP، لا موافقة من خادم الأصل.

لم يصدر الحكم النهائي للتكييف بعد، فضلاً عن النتيجة عند الأصل أو التطبيق. قد تنتهي المرحلة بتعديل أو 204 أو خطأ، ثم يرفض الأصل أو المستلم الناتج.

يجب أن تسمي المقاييس المرسل والمرحلة: طلب بقية الجسم إلى المكيف، قرار المكيف، تسليم HTTP التالي، ثم الأثر الموثق. كلمة «استمر» لا تجمع هذه السلطات.

ieof يثبت أن نهاية الجسم كانت داخل المعاينة

قد لا يعرف الوسيط طول ما سيصل من الأصل. إذا انتهى المصدر أثناء تكوين المعاينة، يضع العميل امتداد ieof على آخر chunk.

يعرف الخادم عندها أن الجسم انتهى فعلاً، فلا يجوز أن يطلب المزيد بـ 100 Continue. يمكنه أن يعيد تعديلاً أو 204 حسب السياق. وتزال علامة ieof قبل تمرير البايتات إلى منطق التطبيق.

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

204 عقد لإعادة الأصل وليس شهادة سلامة

أثناء Preview، يسمح 204 No Content للعميل بالمتابعة كما لو أن الرسالة الكاملة عادت بلا تعديل. يعمل ذلك لأن العميل احتفظ بجزء المعاينة وما زال يملك بقية الأصل.

خارج المعاينة، يعلن العميل Allow: 204 إذا قبل مسؤولية حفظ ما يكفي لإعادة الرسالة. من دون هذا الإذن، على الخدمة إعادة الرسالة المطابقة كاملة حتى عندما لا تعدلها.

إذن يوزع الرمز كلفة الذاكرة والتحكم بالتدفق والاستعادة. لا يعني أن المحتوى نظيف أو أصيل أو مأذون. قد تكون الخدمة غير راغبة في التعديل أو غير قادرة عليه.

ISTag يحدد حالة الخدمة التي قررت

يتطلب RFC 3507 وجود ISTag في كل استجابة ICAP. يمكن أن يمثل الرمز حالة البرمجيات أو الإعداد أو بيانات القرار. وعندما يبطل تغيير ما النتائج السابقة، يساعد تغيير الوسم العميل على إسقاط نتائج مخبأة للعصر القديم.

النطاق أوسع من ETag لتمثيل HTTP منفرد؛ فهو قد يشمل كيانات كثيرة أنتجها URI واحد للخدمة. لكن الرمز ليس توقيعاً، ولا يكشف القواعد، ولا يثبت أن كل عقد العنقود انتقلت معاً.

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

للقدرات والنتائج والقواعد ساعات مختلفة

يعلن OPTIONS الأساليب وحجم Preview ومعالجة النقل وAllow والاتصالات القصوى ومدة الخيارات وISTag. لهذا الرد عمر. وللنتيجة المعدلة عمر تخزين آخر. وقد تتغير حالة الخدمة بينهما.

في RESPMOD لا يجوز أن يمتد انتهاء الكائن المعدل لما بعد انتهاء كائن الأصل، وإن أمكن تقصيره. تحمي القاعدة حد حداثة الأصل، ولا تثبت أن قواعد التكييف بقيت كما هي.

ينبغي أن يسجل قرار إعادة الاستخدام عمر OPTIONS وحداثة HTTP وصلاحية وسم الخدمة في اللحظة نفسها. قراءة القيم الحالية بعد الحادثة لا تعيد الماضي.

إزاحات التغليف خريطة وليست تصديقاً

يعطي رأس Encapsulated مواقع رؤوس وأجسام الطلب والاستجابة، أو جسم OPTIONS، أو الجسم الخالي. يسمح بفصل الرسالة المركبة، لكنه لا يثبت صحة كل دلالة HTTP ولا سلامة التحويل.

إطار chunks ونهاية Preview وieof وحالة ICAP وحالة HTTP المضمنة طبقات مختلفة. إعادة تسلسل HTTP وحده قد تمحو الحد الذي يفسر من رأى أي بايت.

السلطة السياسية تقع خارج الحالة

ناقش RFC 3238 ووثائق OPES اللاحقة الموافقة والإخطار والخصوصية والقواعد ونطاقات الثقة والتتبع. لا تجعل تلك النصوص كل نشر ICAP تطبيقاً لـ OPES، ولا تضيف إذناً تلقائياً إلى رمز حالة.

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

سلسلة تثبت من قال ماذا

ابدأ ببايتات HTTP الأصلية ودورها ونقطة رصدها. سجل URI وأسلوب ICAP والأطراف وOPTIONS وانتهاءه وISTag. تحقق من إزاحات التغليف.

سجل Preview المطلوبة والمستلمة وieof وحالة قراءة الأصل والمخزن المؤقت. احفظ الرد المؤقت أو النهائي والبقية المرسلة والبايتات التي شاهدتها الخدمة.

للتحويل احتفظ بما قبل وما بعد والقاعدة. وللتخزين احتفظ بالمفتاح والتواريخ والوسم. ولـ 204 أثبت إعادة الأصل. ثم تتبع قفزة HTTP التالية والمصدر والتسليم والتفويض ونتيجة التطبيق الموثقة.

حدود الدليل

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

كما لا يكرر المقال القائم عن HTTP 100 Continue، الذي يدرس إذن إرسال الجسم على حد HTTP. هنا الموضوع هو مصدر الاستجابة داخل مسار تكييف مفوض.

مبادئ Heng Lu بشأن الحد الأدنى للمواصفة الأولية وأولوية الشفرة العاملة عدسات تحريرية معلنة. إنها تفضل عقداً مشتركاً ضيقاً ودليلاً من المسار المنفذ، وليست قياساً لاعتماد ICAP.

الخلاصة محددة: تشابه الصيغة لا ينقل السلطة. قبل إسناد خطأ HTTP إلى الأصل، يجب إثبات أن الأصل أنشأه.

Sources