Squid बाह्य ACL क्यासिङ: हेल्परलाई हरेक पटक किन बोलाइँदैन

एउटा अनुरोध लग गरेर चुप हुने हेल्पर सामान्य हुन सक्छ। Squid ले हेल्परलाई अर्को प्रश्न नपठाई क्यास गरिएको बाह्य ACL नतिजाबाट नियम मूल्याङ्कन गर्न सक्छ।

पहिले पुन: प्रयोगयोग्य निर्णय परिभाषित गर्नुहोस्। “यो खाताले प्रोक्सी प्रयोग गर्न सक्छ?” लाई “यो खाताले यो गन्तव्यमा पुग्न सक्छ?” भन्दा फरक इनपुट चाहिन्छ। विस्तारित बाह्य ACL ढाँचाले क्यास कुञ्जी बनाउँछ। हेल्परले प्रयोगकर्तानाम र गन्तव्यद्वारा निर्णय गर्छ तर कुञ्जीमा प्रयोगकर्तानाम मात्र छ भने, क्यास गरिएको स्वीकृति अपेक्षाभन्दा फराकिलो रूपमा लागू हुन सक्छ। उत्तर परिवर्तन गर्ने प्रत्येक इनपुट समावेश गर्नुहोस् र समान निर्णयहरूलाई मात्र टुक्राउने विवरणबाट बच्नुहोस्।

त्यसपछि ताजगी छान्नुहोस्। सकारात्मक ttl र negative_ttl ले मिल्ने र नमिल्ने नतिजा नियन्त्रण गर्छन्; grace एन्ट्री समाप्त हुनुअघि रिफ्रेस सुरु गर्न सक्छ। रद्द गरिएको खाताको क्यास गरिएको स्वीकृतिले पछिका निर्णयमा कति समय प्रभाव पार्न सक्छ भनी निर्धारण गर्नुहोस्। यीमध्ये कुनै पनि सेटिङले स्थापित CONNECT सुरुङलाई प्रत्येक बाइट वा आन्तरिक HTTPS अनुरोधका लागि पुन: अधिकृत गर्दैन। हेल्परले ट्राफिक कोटा लागू गर्छ भने, बाँकी परिवर्तन भएपछि पनि स्वीकृत स्थानान्तरण जारी रहन सक्छ।

हेल्पर स्थायी प्रोटोकल सहभागी हो, प्रत्येक अनुरोधका लागि नयाँ स्क्रिप्ट प्रक्रिया आवश्यक हुँदैन। क्रमिक प्रश्न लाइनहरूका लागि तयार राख्नुहोस् र प्रत्येक उत्तर तुरुन्तै पठाउनुहोस्। निदान अर्को च्यानलमा राख्नुहोस्। समवर्तीता सक्षम हुँदा सम्बन्धित दिइएको च्यानल पहिचानकर्ता फर्काउनुहोस्।

अन्तमा, ढिलो, अनुपलब्ध र आन्तरिक त्रुटि नतिजा परिभाषित गर्नुहोस् र वरपरको ACL क्रमले ती उत्पन्न गरोस्। पुन: प्रयोगयोग्य उत्तरको विशिष्टता र अनुमत उमेर दुवै पहुँच आवश्यकतासँग मिल्दा डिजाइन पूर्ण हुन्छ।