Squid हुँदै डाउनलोड फेरि जारी गर्नुहोस्
फाइल जारी गर्नुअघि Range प्रतिक्रिया र वस्तुको समानता जाँच्नुहोस्। Squid को प्रिफेच नीतिलाई आधारभूत Range समर्थनबाट छुट्याउनुहोस्।
download.part अहिले माग्ने वस्तुको त्यही प्रतिनिधित्वको हिस्सा भए मात्र डाउनलोड जारी गर्नुहोस्। फाइल नामले मात्र यो प्रमाणित गर्दैन: मूल सर्भरले पहिलो प्रयासपछि सामग्री बदलिसकेको हुन सक्छ।
curl --proxy http://proxy.example:3128 --noproxy '' --connect-timeout 5 --max-time 60 -C - --output download.part http://files.example/test.binदुवै एन्डपोइन्ट प्रयोग गर्न अनुमति भएका सेवाले बदल्नुहोस्। सार्वजनिक प्रोक्सी मान्य ठाउँमा सार्वजनिक फाइल तुलना गर्न HTTP प्रोक्सी सूचीबाट HTTP एन्डपोइन्ट लिनुहोस्। -C - ले रहेको फाइलको आकारलाई जारी गर्ने बिन्दु बनाउँछ। फर्किएको कुनै पनि बडीलाई बाँकी बाइट नठानी गन्तव्यको प्रतिक्रिया हेर्नुहोस्:
| प्रतिक्रिया | अर्थ |
|---|---|
| Content-Range सहित 206 | फर्किएको दायरा अपेक्षित अर्को भाग हो कि जाँच्नुहोस्। |
| 200 | सर्भरले Range बेवास्ता गरेर पूरा प्रतिनिधित्व पठाएको हुन सक्छ। |
| 416 | मागिएको दायरा पूरा हुन सक्दैन; त्रुटिको पृष्ठ फाइलमा नजोड्नुहोस्। |
भ्यालिडेटर र If-Range ले बदलिने स्रोतका फरक संस्करण जोड्नबाट बचाउन सक्छन्। पूरा फाइलमा विश्वास गर्नुअघि एपका प्रतिनिधित्व नियम पालना गर्नुहोस्।
Squid 6.13 को range_offset_limit ले क्यासका लागि वस्तु कहिले सुरुदेखि लिने भन्ने तोक्छ, क्लाइन्टले दायरा माग्न पाउँछ कि पाउँदैन भन्ने होइन:
range_offset_limit 0शून्य सीमाले क्यास भर्न मात्र सुरुआती थप भाग लिनबाट बचाउँछ। वस्तु क्यास नगरी उपयोगी दायरा पठाउनु पनि सफल हुन सक्छ। सामान्य HTTPS CONNECTमा Range आदानप्रदान गन्तव्यको TLS भित्र हुन्छ; त्यो प्रतिक्रिया पढ्नुहोस्, Squid को देखिने वस्तु क्यास नीतिलाई भित्री अनुरोधको नियन्त्रण नठान्नुहोस्।