अनुरोध, कनेक्शन और सत्रों में प्रॉक्सी रोटेशन
हर एप्लिकेशन अनुरोध में Connection: close जोड़ने से पहले जाँचें कि रोटेटिंग प्रॉक्सी सेवा वास्तव में क्या घुमाती है।
एक ही गेटवे से गुजरने वाला दूसरा अनुरोध वैध रूप से वही सार्वजनिक IP उपयोग कर सकता है। जाँचें कि सेवा अपने रोटेशन के लिए कौन-सा जीवनकाल उपयोग करती है:
| रोटेशन इकाई | क्या तुलना करें |
|---|---|
| अनुरोध | अगला एप्लिकेशन संचालन और उसका देखा गया निर्गम |
| कनेक्शन | क्या क्लाइंट ने संगत कनेक्शन दोबारा उपयोग किया या दूसरा खोला |
| प्रदाता सत्र | प्रलेखित स्टिकी-सत्र इनपुट और उसका जीवनकाल |
Connection: close कोई सार्वभौमिक गेटवे निर्देश नहीं है। CONNECT के भीतर HTTPS के लिए, वेबसाइट का अनुरोध हेडर गंतव्य के TLS के भीतर यात्रा करता है। यह बाहरी प्रॉक्सी को नहीं बताता कि कौन-सा सार्वजनिक IP आवंटित किया जाए। HTTP/1.1 की कनेक्शन-विशिष्ट अर्थ-व्यवस्था भी हर HTTP संस्करण या परिवहन में अपरिवर्तित नहीं ले जाई जा सकती।
यदि किसी प्रलेखित प्रति-कनेक्शन सेवा को नया कनेक्शन चाहिए, तो क्लाइंट द्वारा समर्थित जीवनचक्र नियंत्रण का उपयोग करें और बार-बार होने वाली TCP/TLS सेटअप लागत को ध्यान में रखें। यदि रोटेशन प्रदाता सत्र का अनुसरण करता है, तो दोबारा कनेक्ट करने पर वह सत्र और उसका निर्गम दोनों बने रह सकते हैं।
अनुरोध पहचानकर्ता, एंडपॉइंट, प्रासंगिक सत्र कुंजी और गंतव्य पर देखा गया स्रोत अलग-अलग दर्ज करें। कनेक्शन बंद करना केवल उस जीवनचक्र घटना को सिद्ध करता है; अगले संचालन के लिए चुने गए निर्गम को सेवा के वास्तविक रोटेशन अनुबंध के विरुद्ध सत्यापित करें।