Multipart Form Data: أخطاء شائعة عند اختبار رفع الملفات

multipart/form-data يسمح بإرسال ملف وحقول في طلب واحد. الأدوات والمكتبات عادة تبني boundary تلقائيًا، لكن نسخ header يدويًا أو خلط اسم الحقل يجعل server يرى body غير قابلة للتحليل. اختبار الرفع يجب أن يراجع ما أرسل فعليًا لا شكل form في الواجهة.

دع المكتبة تولد Boundary

عند استخدام FormData في browser، لا تضبط Content-Type يدويًا؛ سيضيف المتصفح boundary. إذا كتبت multipart/form-data بلا boundary قد يرفض server الطلب.

تأكد من اسم الحقل

Backend قد ينتظر file أو upload أو files[]. اسم مختلف ينتج missing file رغم وجود bytes. راجع API contract أو request ناجح.

راجع filename و MIME

Content-Type للجزء قد يؤثر على validation لكن لا تثق به أمنيًا؛ server يجب أن يفحص المحتوى. في الاختبار، استخدم ملفات صغيرة معروفة ثم حالات حدودية.

اختبر حدود الحجم

413 قد يأتي من reverse proxy قبل التطبيق. اعرف limits في Nginx/app/storage. ارفع حجمًا تحت الحد وفوقه للتأكد أن الرسالة مفهومة.

راقب Progress وال Timeout

ملف كبير يقيس upload bandwidth وقد يحتاج timeout مختلفًا عن API صغيرة. لا تخلط فشل الشبكة مع validation بعد اكتمال الرفع.

نظف الملفات المؤقتة

Backend قد يكتب temp file قبل validation. اختبر أن الفشل لا يترك ملفات مهجورة وأن filename لا يسمح path traversal.

اختبر Streaming وملفات ذات أسماء صعبة

ملف 10MB قد يعمل بينما 2GB يستهلك RAM إذا كانت المكتبة تجمع body بالكامل. راقب memory أثناء رفع متزامن واستخدم streaming/backpressure حيث يلزم. اقطع الاتصال منتصف الرفع وتأكد أن temp file تُحذف ولا تبقى مساحة مهدرة. من ناحية الاسم، جرّب Unicode عربيًا، مسافات، اسمًا طويلًا، ومحاولات path traversal مثل ../. الخادم يجب أن يولد اسم تخزين داخليًا ولا يستخدم filename مباشرة كمسار. اختبر Windows و Linux لأن المحارف المحجوزة والفواصل تختلف. هذه الحالات تجمع الاعتمادية والأمان في نفس suite بدل اعتبار upload ناجحًا بمجرد وصول ملف صغير عادي.

افحص Content Sniffing وامتداد الملف

لا تثق في MIME المرسل أو امتداد filename وحدهما عند حفظ ملفات من مستخدمين. في بيئة الاختبار ارفع ملفًا بامتداد صورة ومحتوى نصي أو العكس، وتأكد أن validation policy تتصرف كما هو مصمم. عند تقديم الملفات لاحقًا، استخدم Content-Type و Content-Disposition مناسبين وامنع التنفيذ غير المقصود داخل نفس origin.

من المثال إلى تطبيق يمكن صيانته

في «Multipart Form Data: أخطاء شائعة عند اختبار رفع الملفات» جرّب الحل على حالة صغيرة ثم أضف failure path واضحًا واختبارًا آليًا يحمي السلوك المتوقع. حدّد contract للمدخلات والمخرجات، وتعامل مع القيم الناقصة قبل الوصول إلى طبقة التنفيذ. إذا كان الحل يتعامل مع API أو ملف أو DOM، أضف logging مختصرًا يوضح المرحلة وكود الخطأ دون بيانات حساسة. بعد ذلك اختبر التوافق مع نسخة سابقة أو بيئة مختلفة. هذه الخطوات تجعل المثال مفيدًا في مشروع حقيقي بدل أن يبقى snippet يعمل فقط في المسار المثالي.

توثيق النتيجة للفريق

بعد الانتهاء من اختبار «Multipart Form Data: أخطاء شائعة عند اختبار رفع الملفات»، احفظ ملخصًا قصيرًا يوضح البيئة والخطوات والنتيجة وما الذي تغير عن ال ـbaseline. أرفق أكواد الأخطاء أو المقاييس الضرورية فقط، واربطها برقم الإصدار. هذا السجل يجعل المراجعة اللاحقة أسرع ويمنع إعادة نفس النقاش من الصفر، كما يسمح لفريق آخر بتكرار التجربة دون الاعتماد على ذاكرة الشخص الذي نفذها. إذا كانت النتيجة غير حاسمة، اكتب ذلك صراحة وحدد الاختبار التالي بدل تحويل الاحتمال إلى استنتاج نهائي.