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