الخلاصة

  • كان 340 دعوة إلى إرسال المقال، أما 240 أو 441 فلم يأت إلا بعد وصول النص كاملا.
  • قد يضيع الرد الإيجابي في طريق العودة من دون أن يتراجع الخادم عن القبول الذي أنجزه.
  • حفظ Message-ID نفسه جعل الإعادة قابلة للتعرف بوصفها المقال ذاته، من دون مساواة القبول بالظهور الفوري أو ضمان التنفيذ مرة واحدة.

انتهى الإرسال وبقيت النتيجة مجهولة

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

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

منح POST إذنين مختلفين

عرّف RFC 977 التسلسل على مرحلتين. يرد الخادم أولا بـ 340 ليطلب المقال أو بـ 440 لمنع النشر. وبعد الترويسات والمتن وسطر النقطة يعطي 240 للنجاح أو 441 للفشل.

إذن لم يكن 340 إيصال قبول، بل فتحا لقناة الإدخال. حافظ RFC 3977 على الفصل ومنع تمرير POST في خط أنابيب. فالزوج الأول يجيب الأمر، والزوج الثاني يحكم على المقال بعد اكتمال نقله.

ينبغي أن يعني 240 أن المقال، ما لم يقع خطأ خادم غير متوقع، سيصبح متاحا محليا أو ينقل إلى خوادم أخرى حسب الحاجة، وربما بعد معالجة إضافية. والمقال غير المرغوب ينبغي رفضه بـ 441 بدلا من قبوله ثم إسقاطه بصمت.

القبول ليس شاشة القراءة

يشدد RFC 3977 على حدين: لا يفترض العميل النجاح ما لم يتلق ردا إيجابيا، ولا يفترض بعد ذلك أن المقال متاح للقراء من دون فحص صريح مثل STAT.

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

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

فضل البروتوكول الاسم الثابت على الاستدلال المتعجل

يتناول RFC 3977 انقطاع الجلسة قبل تلقي النتيجة مباشرة. ربما أرسل الخادم ردا إيجابيا ثم ضاع. في جلسة لاحقة ينبغي للعميل أن يتحقق من نجاح النشر قبل الإعادة، أو يضمن أن المحاولة الجديدة تحصل على Message-ID نفسه.

يفضل المعيار الخيار الثاني لأن المقال قد لا يكون قابلا للقراءة بعد، ومن أمثلته انتظار الإشراف. ويوصي الملحق بأن يتضمن كل POST لمقال بريد أو Netnews حقل Message-ID مطابقا، وأن يتعرف الخادم على المحاولتين بوصفهما المقال ذاته.

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

سجل التاريخ حد الازدواج ولم يلغ المخاطر

يعرّف RFC 5536 Message-ID معرفا فريدا ويبين اعتماد Netnews الكبير على المقارنة السريعة. وبسبب الانتشار بأسلوب الإغراق، قد يعرض عدة جيران المقال نفسه؛ لذلك يطلب RFC 5537 من وكلاء الترحيل والخدمة الاحتفاظ بتاريخ للمعرفات التي رأوها ورفض التكرار.

تتيح الهوية الثابتة ربط المحاولة الجديدة بالمقال المعروف. لكنها لا تضمن «مرة واحدة بالضبط»: سجلات التاريخ محدودة العمر، والسياسات المحلية تختلف، وقد يقع العطل حول لحظة الحفظ الدائم. القيمة هي قابلية المطابقة. يمكن تتبع استلام المتن والرد والإدخال والإشراف والترحيل والقراءة كمراحل منفصلة لمقال واحد.

يسجل سجل IANA لمعاملات NNTP القدرة POST ويشير إلى RFC 3977. التسجيل يمنح اسما مشتركا، لكنه لا يثبت أن خادما بعينه يسمح بالنشر أو يحتفظ بتاريخ كاف.

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

Sources