مهلت‌های بی‌کاری پروکسی در طول کارهای طولانی HTTP
وقتی کار طولانی سرور به حد بی‌کاری پروکسی می‌رسد، به‌جای درج بایت‌های دلخواه در پاسخ نهایی، نظرسنجی یا قالب جریان مشخصی را انتخاب کنید.
اگر سرویسی دقیقه‌ها ساکت بماند و پروکسی مهلت بی‌کاری پیدا کند، پیش از افزودن بایت‌های ضربان انتخاب کنید کلاینت چه چیزی باید دریافت کند. تمدید یک تایمر می‌تواند به یک انتظار کمک کند؛ قرارداد پاسخ تعیین می‌کند کدام پیشرفت معتبر است.
| طراحی برنامه | قرارداد پیشرفت |
|---|---|
| کار ناهمگام | 202 Accepted با نمایشی که پایش را توصیف می‌کند، سپس درخواست‌های وضعیت متناهی و حالت‌های صریح تکمیل/شکست |
| جریان Server-Sent Events | Content-Type: text/event-stream و رکوردهایی که کلاینت SSE می‌فهمد |
202 وعده نمی‌دهد که کار موفق می‌شود. برای SSE، یک رکورد نظر می‌تواند چنین باشد:
: heartbeat
دونقطه آن را به جای رویداد برنامه، نظر می‌کند. یادداشت‌های نگارش HTML نظرهای دوره‌ای تقریباً هر 15 ثانیه را در برابر برخی رفتارهای بی‌کاری قدیمی پروکسی پیشنهاد می‌کنند؛ این یک راهنماست، نه تضمین مهلت جهانی.
سرآیندها را تمام کنید و مطمئن شوید که برنامه/پشته سرویس‌دهی رکوردها را آزاد می‌کند نه اینکه آن‌ها را به‌صورت محلی بافر کند. بایت‌هایی که هنوز ارسال نشده‌اند نمی‌توانند یک واسطه پایین‌دستی را فعال نگه دارند.
نظرهای SSE را در محتوای JSON یا دودویی معمولی وارد نکنید. یک قطعه با طول صفر در HTTP/1.1 بدنه chunked را پایان می‌دهد، پس ضربان خالی تکرارشدنی نیست.
یک مهلت عملیات و سیاست لغو را حفظ کنید. فقط فعالیت ترافیک پیشرفت مفید کار یا نتیجه نهایی معتبر را نشان نمی‌دهد.