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