الخلاصة

  • لا تمنح بنية multipart السرية أو سلامة المحتوى أو الإذن بمعالجة ملف. كما لا تجعل اسم الملف الذي يرسله العميل أمراً يحدد موقع تخزينه.
  • تمنع مواصفة 2015 دمج الأجزاء ذات الاسم نفسه وإعادة ترتيب النتائج في الوسطاء؛ لذلك قد يصل الطلب كاملاً ثم يفقد معلوماته عند تحويله إلى قيمة واحدة لكل اسم.

هل أُرسل الملف الصحيح إلى الجهة التي قصدها صاحبه؟ لا يجيب نجاح تحليل النموذج عن هذا السؤال. فقد شددت مسودة رفع الملفات التي شارك فيها Larry Masinter عام 1995 على الحذر من إرسال ملفات محلية لم يطلب المستخدم صراحة إرسالها. وبعد عشرين عاماً، بقيت المسؤولية خارج شكل البيانات نفسه. هذه الاستمرارية مهمة: تحسين طريقة حمل المعلومات لا يلغي ضرورة تقرير ما يجوز فعله بها.

إذن الاستخدام لا يأتي مع اسم الملف

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

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

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

معلومتان لهما الاسم نفسه

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

يعالج القسم 5.2 من مواصفة 2015 الحدود التي يكشفها المثال. ينبغي لمعالجات النماذج ذات الترتيب المحدد أن تعيد النتائج بالترتيب. ويحظر على الوسطاء إعادة ترتيبها، كما يحظر دمج الأجزاء ذات أسماء الحقول المتطابقة. توصية الترتيب للمعالج ليست إلزاماً بإيجاد ترتيب طبيعي لكل نموذج؛ أما المنعان فيحافظان على الفروق الموجودة بالفعل.

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

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

كيف وصلت المواصفة إلى هذه الحدود؟

نشر E. Nebel وL. Masinter RFC 1867 في نوفمبر 1995. اقترح إضافة لاختيار الملفات في نماذج HTML، وتمثيلاً متوافقاً مع MIME، وخطة انتقال للمتصفحات القديمة، حين لم تكن النماذج العادية تتيح طلب ملفات محلية بصورة موحدة. وكانت فئته Experimental؛ لم يدّع أنه معيار للإنترنت.

جاء RFC 2388، باسم L. Masinter، على مسار المعايير في أغسطس 1998. ترك قسمه 5.5 علاقة ترتيب الحقول بترتيب النتائج، ومعالجة الأسماء المتكررة، دون تعريف. ثم حل RFC 7578 محله في 2015 ووضح هاتين النقطتين. تحمل الوثيقة الأخيرة اسم المؤلف، لكنها تسجل أيضاً مراجعة علنية وإجماع مجتمع IETF. لا يصح تحويل هذا الإسهام المستمر إلى ادعاء بأن شخصاً واحداً اخترع كل سلوك المتصفحات أو أساس MIME.

المجال أوسع من زر الرفع المعتاد: تعرف مواصفة 2015 دلالات عامة تتجاوز HTML وHTTP، وتشمل تطبيقات لا يملأ فيها شخص نموذجاً ظاهراً. وتعترف بتاريخ متنوع لترميز المحارف. توصي بأسماء حقول ASCII لتسهيل التشغيل البيني، أو استخدام UTF-8 بصورة متسقة عندما يتعذر تجنب غيرها؛ وتوثق أعراف مجموعة المحارف الافتراضية. وتحظر filename* في هذا التنسيق، فلا يمكن استعارة قاعدة من سياق آخر للترويسات دون تدقيق.

المصادر وما لا تثبته

تستند القراءة إلى الوثائق الثلاث وروابطها أعلاه، وإلى صفحة المؤلف الشخصية القديمة ذات السياق الزمني لعام 2014. الصفحة لا تثبت وظيفته الحالية. ولم تُجر دراسة للمكتبات المستخدمة اليوم أو قياس لفقد البيانات أو اختبار هجوم. الاستنتاجات التشغيلية تحليل تحريري. أما الصورة العامة المرجعية فتثبت ملامح الهوية المستخدمة في صورة تحريرية مولدة بالذكاء الاصطناعي؛ ومشهد العمل خلفها متخيل، لا مكتب حقيقي موثق.