الخلاصة

  • مثّلت RFC 1867 ثم RFC 2388 ملفات متعددة ضمن خانة واحدة على هيئة جزء multipart/mixed داخل multipart/form-data.
  • سجّلت RFC 7578 أن المرسلين الذين يطبقون هذه البنية لم يكونوا معروفين، فخصّصت جزءاً خارجياً لكل ملف يحمل اسم الخانة نفسه، مع إبقاء التوافق لدى جهات الاستقبال مع الصيغة المتداخلة الأقدم.

الخانة احتاجت إلى صيغة إرسال

قبل أن تتمكن نماذج المتصفح من إرسال محتوى الملفات المحلية بطريقة مشتركة، احتاجت الخدمات أحياناً إلى عميل مخصص. اقترحت RFC 1867 عام 1995 عنصر HTML باسم INPUT TYPE=FILE وتمثيلاً من MIME يحمل قيم الخانات العادية وبيانات الملفات معاً. كان تصنيف الوثيقة تجريبياً، لا معياراً مكتملاً للإنترنت، كما تناولت التوافق مع وكلاء المستخدم الذين لم يستطيعوا الرفع بعد.

تكوّن الشكل من مستويين. يعرّف الجزء الخارجي multipart/form-data اسم خانة النموذج. وإذا اختار المستخدم عدة ملفات في الخانة نفسها، احتوى جزء داخلي من نوع multipart/mixed على تلك الملفات. كان التقسيم منطقياً في الوثيقة: غلاف يربط البيانات بالخانة وغلاف آخر يجمع الملفات.

جعلت RFC 2388، المنشورة عام 1998 ضمن مسار المعايير، multipart/form-data مستقلة عن HTML وHTTP كي تستخدمها تطبيقات أخرى تعيد قيماً من نموذج. لكنها أبقت الجزء الداخلي multipart/mixed عندما تحمل الخانة مجموعة ملفات. انتقل الشكل المقترح تجريبياً إلى وثيقة قابلة لإعادة الاستخدام من دون تغيير هذا التفصيل.

المراجعة لم تجد مرسلاً معروفاً لهذا الشكل

استبدلت RFC 7578 الوثيقة السابقة عام 2015 وسجلت الفجوة بوضوح غير معتاد: لم تعد البنية المتداخلة موصى بها لمنشئي الرسائل، ولم يعد مطلوباً من جهات الاستقبال تنفيذها، لأن المرسلين الذين يطبقونها لم يكونوا معروفين. ولمطابقة التطبيقات التي أمكن التعرف عليها، صار لكل ملف جزء خارجي مستقل؛ وتكرر الأجزاء التابعة لخانة واحدة وسيط name نفسه.

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

عبارة «لا توجد تطبيقات إرسال معروفة» تصف ما استطاع مؤلفو RFC 7578 إثباته، ولا تبرهن أن أي برنامج لم يرسل الشكل المتداخل قط. لا تسمي الوثيقة متصفحاً أو خادماً، ولا تقدم حصة سوقية أو تاريخ تحول أو معدل فشل. لكنها تثبت أمراً أضيق: عُدّل وصف معياري لأن المؤلفين لم يستطيعوا الإشارة إلى تطبيقات ترسل البنية التي وصفتها الوثيقة السابقة.

تكرار الاسم يحفظ القيم منفصلة

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

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

الشيفرة العاملة دليل لا شعار

يركز نص Heng Lu عن أولوية الشيفرة العاملة على الفرق بين نص المواصفة والسلوك المنفذ فعلاً. تقدم RFC 2388 مثالاً محدوداً وواضحاً: لم تحتفظ RFC 7578 بالتوصية القديمة لمجرد أنها كُتبت سابقاً. عدّل مؤلفوها بنية الملفات المتعددة لتوافق المرسلين الذين استطاعوا توثيقهم، مع إبقاء متطلبات التوافق عند جهة الاستقبال.

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

المصادر