توقفات رفع HTTP و Expect: 100-continue
تعرّف على تبادل Expect: 100-continue وميّز نقطة القرار القصيرة فيه عن عملية رفع توقفت أثناء نقل البيانات.
يُفتح الاتصال. تخرج ترويسات الطلب. يبدو أن الملف لا يتحرك. أحد التفسيرات أن العميل ينتظر ردًّا على Expect: 100-continue قبل إرسال جسمه.
تتيح هذه الآلية للمستقبل رفض الطلب بناءً على ترويسته قبل إرسال عملية رفع قد تكون كبيرة. التسلسل الناجح المعتاد هو:
request headers → 100 Continue → request body → final responseالرمز 100 إعلامي: يسمح للعميل بالمتابعة، لكنه لا يعني أن الملف قد خُزّن أو أن عملية التطبيق قد نجحت. دفع Git يعيد HTTP 417 هو حالة واحدة ملموسة لفشل التوقع.
حدّد الرد الذي تلقاه العميل
| الملاحظة | المعنى الذي يجب فحصه |
|---|---|
| 100 Continue | يمكن للعميل المتابعة بالجسم |
| رفض نهائي قبل الجسم | رُفضت العملية في مرحلة الترويسات |
| لا رد مرحلي متوقع | سياسة انتظار العميل والمعالجة على ذلك المسار |
يوفر curl إعدادًا مخصصًا للانتظار الخاص بـexpect-continue. إذا انتهت مهلة انتظار libcurl دون الرد المتوقع، فإنه يرسل الجسم على أي حال؛ انتهاء المهلة ليس تلقائيًا فشلًا للنقل بأكمله. الإعداد منفصل عن الوقت المسموح للنقل الكامل. وزيادة الأخير قد تترك نفس التوقف الأولي دون تفسير.
حدّد أيضًا محادثة HTTP التي تحمل Expect. مع CONNECT العادي إلى وجهة HTTPS، يكون تبادل الرفع الخاص بالموقع داخل TLS؛ فالوكيل الأمامي لا يفحص ببساطة ترويسة التوقع الداخلية. أما مسار الاعتراض أو التمرير بالنص الصريح فمختلف.
قد تكون إزالة التوقع خيارًا مقصودًا للتوافق، لكنها تعني أن العميل قد يبدأ إرسال جسم كبير قبل أن يعرف بالرفض المبكر. قارن ذلك السلوك بالمتطلب الفعلي. لا تصف حلًّا تاريخيًا لوكيل قديم كتعليمات عامة لإزالة الترويسة من كل عملية رفع.