लांब HTTP कामांदरम्यान प्रॉक्सीच्या निष्क्रियतेच्या कालमर्यादा
जेव्हा लांब सर्व्हर काम प्रॉक्सीच्या निष्क्रियतेच्या मर्यादेला भेटते, तेव्हा अंतिम प्रतिसादात अनियंत्रित बाइट्स घालण्याऐवजी पोलिंग किंवा निर्धारित स्ट्रीमिंग स्वरूप निवडा.
जर एखादी सेवा काही मिनिटे शांत राहिली आणि प्रॉक्सीची वेळ संपली, तर हार्टबीट बाइट्स जोडण्यापूर्वी क्लायंटला काय मिळावे हे निवडा. टाइमर वाढवणे एका प्रतीक्षेला मदत करू शकते; प्रतिसाद करार ठरवतो की कोणती प्रगती वैध आहे.
| अॅप्लिकेशन डिझाइन | प्रगती करार |
|---|---|
| असिंक्रोनस काम | निगराणीचे वर्णन करणाऱ्या प्रतिनिधित्वासह 202 Accepted, त्यानंतर मर्यादित स्थिती विनंत्या आणि स्पष्ट पूर्णता/अपयश स्थिती |
| Server-Sent Events स्ट्रीम | Content-Type: text/event-stream आणि SSE क्लायंट समजतो ते रेकॉर्ड |
202 काम यशस्वी होईल असे वचन देत नाही. SSE साठी, टिप्पणी रेकॉर्ड असे दिसू शकते:
: heartbeat
कोलन त्याला अॅप्लिकेशन इव्हेंटऐवजी टिप्पणी बनवते. HTML च्या लेखन नोट्स काही जुन्या प्रॉक्सी निष्क्रियता वर्तनाविरुद्ध अंदाजे दर 15 सेकंदाला नियतकालिक टिप्पण्या सुचवतात; ते मार्गदर्शन आहे, सार्वत्रिक कालमर्यादा हमी नाही.
हेडर पूर्ण करा आणि अॅप्लिकेशन/सेवा स्टॅक रेकॉर्ड स्थानिक पातळीवर बफर करण्याऐवजी मुक्त करतो याची खात्री करा. अजून न पाठवलेले बाइट्स डाउनस्ट्रीम मध्यस्थाला सक्रिय ठेवू शकत नाहीत.
सामान्य JSON किंवा बायनरी सामग्रीमध्ये SSE टिप्पण्या घालू नका. HTTP/1.1 चा शून्य-लांबी chunk chunked बॉडी संपवतो, म्हणून तो पुनरावृत्तीयोग्य रिकामा हार्टबीट नाही.
ऑपरेशनची अंतिम मुदत आणि रद्द करण्याचे धोरण ठेवा. केवळ रहदारीची हालचाल उपयुक्त कामाची प्रगती किंवा वैध अंतिम निकाल दाखवत नाही.