مهلات الخمول للبروكسي خلال مهام HTTP الطويلة
اختر الاستقصاء أو صيغة بث محددة عندما يصطدم عمل الخادم الطويل بحد الخمول لدى البروكسي، بدل إدراج بايتات عشوائية في الاستجابة النهائية.
إذا بقي خدمة صامتة لدقائق ثم انتهت مهلة البروكسي، فاختر ما ينبغي أن يتلقاه العميل قبل إضافة بايتات النبض. قد يساعد تمديد المؤقت في انتظار واحد؛ لكن عقد الاستجابة هو ما يحدد أي تقدم يكون صالحاً.
| تصميم التطبيق | عقد التقدم |
|---|---|
| مهمة غير متزامنة | 202 Accepted مع تمثيل يصف المراقبة، تتبعه طلبات حالة محدودة وحالات اكتمال/فشل صريحة |
| بث Server-Sent Events | Content-Type: text/event-stream وسجلات يفهمها عميل SSE |
لا يَعِد 202 بأن المهمة ستنجح. بالنسبة إلى SSE، قد يبدو سجل التعليق هكذا:
: heartbeat
النقطتان تجعله تعليقاً لا حدث تطبيق. تقترح ملاحظات تأليف HTML تعليقات دورية كل 15 ثانية تقريباً ضد بعض سلوك الخمول القديم للبروكسي؛ وهذا إرشاد لا ضمان مهلة شامل.
أكمل الترويسات وتأكد من أن حزمة التطبيق/التقديم تحرر السجلات بدل تخزينها مؤقتاً محلياً. البايتات التي لم تُرسل بعد لا يمكنها إبقاء وسيط لاحق نشطاً.
لا تُدرج تعليقات SSE في محتوى JSON أو ثنائي عادي. القطعة ذات الطول الصفري في HTTP/1.1 تنهي جسم chunked، لذا ليست نبضاً فارغاً قابلاً للتكرار.
احتفظ بموعد نهائي للتشغيل وسياسة إلغاء. نشاط الحركة وحده لا يُظهر تقدماً مفيداً للمهمة أو نتيجة نهائية صالحة.