الخلاصة

  • أضافت RFC 1806 القيمتين inline وattachment واسم ملف اختياريًا إلى MIME بوصفها رغبات في العرض والحفظ، لا إيصالات تثبت أن عرضًا أو كتابةً قد حدثا.
  • ظل على الطرف المتلقي حذف معنى المسار، ومنع التصادم والاستبدال، والحيلولة دون أن يشغّل اسم بعيد ملف بدء أو أمرًا أو أنبوبًا من دون فعل صريح من المستخدم.
  • حسّنت RFC 2231 وRFC 8187 تمثيل الأسماء البشرية، بينما وسّعت RFC 6266 وRFC 7578 السياق إلى تنزيلات HTTP والرفع بالنماذج؛ ولم تجعل أي منها دقة الترميز مرادفة للإذن.

عرف MIME مكوّنات الرسالة ولم يعرف شاشة المتلقي

مكّنت RFC 1521 رسالة البريد من حمل نصوص وصور وبيانات تطبيقات وبنى متعددة الأجزاء. ثم نظمت RFC 2045 وRFC 2046 قواعد الترميز وأنواع الوسائط والحاويات. استطاع برنامج الاستقبال أن يفصل الأجزاء ويستعيد بايتاتها ويقرأ النوع الذي صرّح به المرسل.

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

في يونيو/حزيران 1995 اقترحت RFC 1806، وكانت وثيقة Experimental، حقل Content-Disposition اختياريًا لأي كيان MIME. يستطيع المرسل به بيان العرض المرغوب. وإذا غاب الحقل بقي وكيل المستخدم حرًا في اختيار الطريقة المناسبة. أي إن المعيار أضاف قولًا بعيدًا إلى القرار، ولم ينقل القرار نفسه.

قيمتان تنظمان العتبة التالية

تعني inline أن الجزء يُراد عرضه تلقائيًا في السياق العادي، مع الخضوع لقواعد الحاوية متعددة الأجزاء. وتعني attachment أن العرض ينبغي أن ينتظر إجراءً إضافيًا من المستخدم. يمكن أن يكون ذلك رمزًا في واجهة رسومية أو بندًا في قائمة نصية؛ لم يفرض المعيار شكلًا واحدًا.

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

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

أما القيمة غير المعروفة فكان ينبغي معاملتها كمرفق، ويمكن تجاهل المعاملات غير المعروفة. لم تمنح RFC 1806 المصطلح الجديد امتياز العرض التلقائي قبل فهمه؛ بل وضعت الشك في الجهة التي تتطلب فعلًا إضافيًا.

الاسم المقترح لم يكن حدث كتابة

قدّم معامل filename اسمًا افتراضيًا إذا اختار المتلقي فصل الجزء وحفظه. ويمكن أن يرد حتى مع جزء inline لا يُكتب إلى القرص أصلًا. وهكذا لا تكفي رؤية الاسم للقول إن ملفًا أُنشئ.

طلبت RFC 1806 عدم احترام معلومات الأدلة الموجودة في القيمة، واستخدام المكوّن الطرفي بعد ملاءمته لأعراف النظام المحلي، ومنع استبدال ملف موجود. فالمرسل لا يعرف فواصل المسارات، ولا الأسماء المحجوزة، ولا المواقع المسموح بالكتابة فيها، ولا اللاحقات المرتبطة ببرامج، ولا الأسماء المستخدمة على جهاز آخر.

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

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

زادت RFC 2183 خصائص الملف ولم توثق تاريخه

توضح صفحة معلومات RFC 1806 أن RFC 2183 حلت محلها في أغسطس/آب 1997 بوصفها Proposed Standard. احتفظت المراجعة بالقيمتين وبمسؤولية المستقبل عن الاسم، وأضافت تواريخ الإنشاء والتعديل والقراءة وحجمًا تقريبيًا.

جعلت الإضافات الجزء المنقول يشبه سجل ملف، لكنها بقيت ادعاءات منقولة. حذرت RFC 2183 منفذي Unix وPOSIX من أن st_ctime ليس وقت الإنشاء. يستطيع المستقبل أن يختار حفظ التاريخ، لكنه لا يحصل بذلك على تاريخ موثّق. وقد يساعد الحجم التقريبي في تقدير المساحة من دون أن يكون بصمة أو ضمان تخصيص أو إيصال اكتمال كتابة.

وضعت المراجعة أيضًا آلية تسجيل للامتدادات. يضم سجل IANA لـ Content Disposition اليوم القيم الأصلية وقيمًا أضيفت لسياقات بروتوكولية مختلفة. يثبت التسجيل أن للمصطلح تعريفًا عامًا ومرجعًا؛ ولا يثبت أن عميلًا محددًا ينفذه أو أن معناه متطابق في كل موضع.

وسّعت RFC 2231 الاسم من دون توسيع الإذن

اعترفت RFC 1806 بأن قواعدها تقصر اسم الملف على US-ASCII. وكان ذلك قيدًا جوهريًا على قيمة يفترض أن تساعد إنسانًا في التعرف إلى المحتوى. عالجت RFC 2231 القيم الطويلة ومجموعات المحارف واللغة. أتاحت مقاطع مرقمة متتابعة، وصيغة موسعة تحمل اسم مجموعة المحارف ولغة اختيارية وبايتات مرمزة بالنسبة المئوية.

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

ولا تعني سلامة فك الترميز سلامة الاسم. يظل اجتياز الأدلة اجتيازًا وإن كُتب بأبجدية صحيحة، ويظل اسم الجهاز المحجوز خطيرًا وإن عُرض بلا تشويه. حسّنت RFC 2231 التعبير؛ ولم تمنح السلسلة حق السيطرة على فضاء الأسماء المحلي.

سبق استعمال الويب تقنينه

ذكرت RFC 2616 عام 1999 أن Content-Disposition يُنفذ كثيرًا في HTTP رغم أنه لم يكن جزءًا من معيار HTTP آنذاك. احتاج الخادم إلى اقتراح تنزيل منفصل واسم مفيد، كما احتاج مرسل البريد من قبل.

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

يمكن للاستجابة أن تحمل filename للتوافق وfilename* للصيغة الموسعة، وعلى من يفهم الاثنين تفضيل الثانية. ثم نقحت RFC 8187 ترميز معاملات HTTP وأوجبت دعم UTF-8. إذا اختلفت القيمتان، فاختيار إحداهما والمحلل المستخدم والاسم المعروض وقائع تحتاج سجلًا مستقلًا.

في الرفع صار المتصفح هو المرسل

يظهر Content-Disposition أيضًا داخل أجزاء multipart/form-data، لكن RFC 6266 تستبعد هذه الحقول الداخلية من نطاق استجابة HTTP. تشترط RFC 7578 form-data ومعامل name لكل جزء، وينبغي أن يتضمن جزء الملف filename حين يوجد اسم ذو معنى.

هنا يرسل المتصفح الاسم وتتلقى تطبيقات الويب البايتات. يصبح التطبيق مسؤولًا عن إسقاط الدليل، وملاءمة الاسم، واختيار التخزين. وتمنع RFC 7578 استخدام filename* في هذا السياق، مع أنه صحيح في استجابة التنزيل. تشابه اسم الحقل لا يلغي اختلاف الموضع والعقد.

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

المصادر