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