الخلاصة

  • أتاح FEAT اكتشاف امتدادات FTP الموثقة من دون تجربة كل أمر، بينما هيأ OPTS الخيارات لأمر سيأتي بعده.
  • كانت القائمة الإيجابية المتوافقة جردًا كاملًا للامتدادات المدعومة، لكن رد 500 أو 502 لم يثبت غيابها؛ فقد تدعم خوادم قديمة امتدادات سبقت ظهور FEAT.
  • ظل إعلان القدرة وقبول الخيار والمصادقة والتفويض والرد النهائي ونتيجة نقل البيانات إيصالات منفصلة.

حين كان الاستطلاع يحمل أثرًا

لم تبق مجموعة أوامر FTP عند حدود RFC 959. ظهرت امتدادات جديدة، واعتمدتها الخوادم في أوقات مختلفة. معرفة العميل بالمواصفة لم تكن معرفة بحالة الخادم الذي اتصل به للتو.

كان الاختبار المباشر مغريًا: أرسل الأمر، فإن تعرف إليه الخادم عرفت أنه مدعوم. لكن RFC 2389 أوضحت أن هذا الأسلوب يولد سلسلة من التبادلات، وقد يحدث أثرًا غير مرغوب فيه. فالرسالة المصممة لتطلب عملًا ليست استعلامًا محايدًا عن إمكانية العمل.

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

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

مسافة واحدة صنعت حدًا قابلًا للتحقق

تبدأ القائمة غير الفارغة برد متعدد الأسطر من فئة 211-. يوضع كل امتداد في سطر مستقل يبدأ بمسافة واحدة تمامًا، وتنتهي القائمة بـ211 End. لم تكن المسافة تنسيقًا بصريًا؛ بل ضمنت ألا يُفسر سطر قدرة على أنه سطر النهاية.

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

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

لم تُدرج FEAT نفسها في القائمة؛ فكل رد غير 500 أو 502 يثبت أن الخادم يفهمها. ولم يُدرج OPTS لأن تنفيذه لازم لكل من ينفذ FEAT. عكست القائمة مجالها المحدد بدل أن تدعي وصف كل حقيقة في الجلسة.

جواب مكتمل في اتجاه واحد

فرضت RFC 2389 على الخادم الذي ينفذ FEAT أن يسرد كل امتداد FTP موثق يدعمه بعد RFC 959 والوثيقة نفسها. لذلك يستطيع العميل أن يتعامل مع القائمة الإيجابية المتوافقة بوصفها جردًا مكتملًا: ما يغيب عنها غير مدعوم في ذلك السياق.

لكن رد 500 أو 502 يثبت فقط أن الخادم لا يعرف أمر الجرد. انتشرت امتدادات قبل عام 1998، وقد يفهم خادم قديم أحدها من دون أن يعرف كيف يعلنه. لذلك قد يضطر العميل إلى اختبار ذلك الامتداد القديم على حدة.

حتى الخادم الذي يعرف FEAT ولا يملك امتدادات إضافية كان يُستحسن أن يرد بسطر 211 واحد، مع السماح له أيضًا بـ500 أو 502. فمن منظور العميل يصعب عمليًا التفريق بين «لا أعرف آلية القائمة» و«أعرفها لكن قائمتي فارغة».

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

OPTS يهيئ الأمر ولا ينفذه

ليست كل قدرة مفتاحًا ثنائيًا. سمح OPTS للعميل بتحديد أمر هدف وخيارات يرغب في تطبيقها عندما يصدر ذلك الأمر لاحقًا. تحدد وثيقة الأمر صيغة الخيارات وتأثيرها، بينما تقدم RFC 2389 الغلاف المشترك وفئات الردود.

يعني 200 أن الهدف والخيارات معروفان ومناسبان. يشير 501 إلى خطأ دائم سيظل قائمًا إن لم تتغير الحالة. ويشير 451 إلى ظرف مؤقت في الخادم قد يزول. لا يعني أي منها أن العملية النهائية قد حدثت.

تظهر RFC 3659 ذلك في MLST. يمكن لسطر القدرة أن يعدد حقائق الملفات المتاحة ويضع نجمة بجانب ما يُعاد افتراضيًا. ثم يغير OPTS MLST مجموعة الحقائق التي ستظهر في ردود MLST وMLSD التالية. وقد يكون إنتاج بعض الحقائق غير الافتراضية مكلفًا، لذلك حذرت الوثيقة من طلبها بلا حاجة تشغيلية.

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

ظهور AUTH TLS لا ينشئ جلسة محمية

استخدمت RFC 4217 الآلية نفسها لتأمين FTP بواسطة TLS. يعلن الخادم المتوافق AUTH TLS وPBSZ وPROT. تخبر هذه السطور العميل بأن مسار التفاوض متاح، لكنها لا تحمي اتصالًا بعد.

ما زال على العميل إرسال AUTH TLS، وعلى الخادم قبوله بـ234، وعلى الطرفين إكمال تفاوض TLS وضبط الحماية والتحقق من هوية الشهادة بحسب السياسة، ثم إكمال مصادقة مستخدم FTP المطلوبة. لا تمنح قائمة القدرات الإذن، ولا تضمن حماية قناة البيانات أو نجاح نقل ملف.

وتكرر RFC 7151 الحد نفسه مع HOST. إعلان HOST يثبت دعم اختيار مضيف افتراضي، لكن الاختيار قد يغير بيئة المصادقة، ويظل تطابق الاسم مع هوية الشهادة فحصًا مستقلًا. وجود الباب واختيار الباب والثقة بمن خلفه ليست حقيقة واحدة.

السجل يمنع تصادم الأسماء ولا يمنح ختم الجودة

مع تزايد الامتدادات أنشأت RFC 5797 سجل IANA لأوامر FTP وامتداداته. كان الهدف منع استخدام الاسم ذاته لمعنيين متعارضين. يسجل الجدول الأمر ورمز FEAT والوصف والنوع ومتطلبات التوافق والمراجع، ويبقي الأسماء التاريخية حتى لا يعاد استخدامها.

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

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

إفصاح محدود بدل استطلاع بالأوامر

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

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

تكمن قيمة RFC 2389 في أنها جعلت سؤال «ما اللغات الإضافية التي تقول إنك تتحدثها؟» يسبق سؤال «هل ستنفذ هذا الطلب لهذا المستخدم الآن؟». تساعد القائمة في القرار، لكن الشفرة العاملة والرد النهائي والأثر المرصود هي التي تكمل الإثبات.

المصادر