وقفه‌های بارگذاری HTTP و Expect: 100-continue
تبادل Expect: 100-continue را بشناسید و نقطه تصمیم کوتاه آن را از بارگذاری‌ای که هنگام انتقال داده متوقف شده جدا کنید.
اتصال باز می‌شود. سرآیندهای درخواست بیرون می‌روند. به نظر می‌رسد فایل حرکت نمی‌کند. یک توضیح این است که کارخواه پیش از فرستادن بدنه‌اش منتظر پاسخ به Expect: 100-continue است.
این سازوکار به گیرنده اجازه می‌دهد درخواست را بر پایه سرآیندهایش رد کند، پیش از آنکه بارگذاری بزرگ احتمالی فرستاده شود. توالی موفق معمول چنین است:
request headers → 100 Continue → request body → final responseکد 100 اطلاعاتی است: به کارخواه اجازه ادامه می‌دهد، اما به معنای ذخیره شدن فایل یا موفقیت عملیات برنامه نیست. یک Git push که HTTP 417 برمی‌گرداند، یک مورد مشخص از شکست انتظار است.
مشخص کنید کارخواه کدام پاسخ را دریافت کرده است
| مشاهده | معنایی که باید بررسی شود |
|---|---|
| 100 Continue | کارخواه می‌تواند با بدنه ادامه دهد |
| رد نهایی پیش از بدنه | عملیات در مرحله سرآیند رد شد |
| هیچ پاسخ میانی مورد انتظاری نیست | سیاست انتظار کارخواه و نحوه برخورد در آن مسیر |
curl تنظیم اختصاصی انتظار برای expect-continue ارائه می‌دهد. اگر آن انتظار libcurl بدون پاسخ مورد انتظار منقضی شود، بدنه را به هر حال می‌فرستد؛ انقضا به‌طور خودکار به معنای شکست کل انتقال نیست. این تنظیم از زمانی که برای انتقال کامل مجاز است جداست. افزایش دومی می‌تواند همان وقفه آغازین را بی‌توضیح بگذارد.
همچنین مشخص کنید کدام گفت‌وگوی HTTP حامل Expect است. در CONNECT معمول به مقصد HTTPS، تبادل بارگذاری وب‌گاه درون TLS است؛ پیشکار رو به جلو به‌سادگی سرآیند انتظار درونی آن را بازرسی نمی‌کند. مسیر رهگیری یا ارسال متن آشکار متفاوت است.
حذف انتظار می‌تواند انتخابی آگاهانه برای سازگاری باشد، اما یعنی کارخواه ممکن است پیش از آگاهی از رد زودهنگام، فرستادن بدنه بزرگ را آغاز کند. آن رفتار را با نیاز واقعی مقایسه کنید. یک راه‌حل تاریخی برای پیشکار قدیمی را به عنوان دستور عمومی حذف این سرآیند از هر بارگذاری توصیف نکنید.