تحقق من رد FTP النهائي قبل الاعتماد على عملية رفع

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

الرد المبدئي مقابل الرد النهائي

بالنسبة إلى STOR، يُعد الرد 125 أو 150 مبدئياً. وهو يعني أن الخادم مستعد للمحاولة وأن اتصال بيانات يُفتح، لا أن الكائن موجود في صيغته النهائية. لا تكتمل العملية إلا عندما يصل النقل إلى رد إنجاز إيجابي، وهو عادة 226 أو 250، في سياق تلك العملية.

الرد 426 يعني أن النقل أُجهض، والرقم الذي يطبعه أمر آخر ليس نتيجة عملية الرفع هذه. اقرأ الرد الذي يخص STOR، لا آخر رقم على الشاشة. وإذا خرج العميل قبل وصول ذلك الرد، فليس لديك أي دليل على الإنجاز.

اتصال التحكم مقابل اتصال البيانات

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

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

FTP عبر TLS مقابل SFTP

FTP عبر TLS يبقى FTP: اتصالان، وردود FTP، وترقية TLS على كل منهما. أما SFTP فهو نظام فرعي من SSH باتصال واحد ومجموعة أوامر مختلفة تماماً. يشتركان في الغرض ولا يكادان يشتركان في شيء آخر، لذا فإن تشخيصاً ينتقل بينهما يبدأ عادة بمقارنة السجلات الخاطئة.

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

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

اسم ملف ظاهر مقابل كائن مخزَّن

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

الوضعان الثنائي وASCII مقارنة أخرى تغيّر النتيجة. قد يحوّل وضع ASCII نهايات الأسطر، فتختلف البايتات المخزَّنة عن الملف المحلي رغم نجاح النقل. أبقِ الوضع الثنائي لفحص بايت ببايت، ولا تضف خيارات تحويل لتجعل نقلاً فاشلاً يبدو مختلفاً.

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

ما ينبغي مقارنته قبل إعادة المحاولة

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

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