http अनुरोधों में "& rnd =" पैरामीटर का उद्देश्य क्या है?

Question

सब!

कुछ वेब-एप्लिकेशन http-get पैरामीटर का उपयोग क्यों करते हैं "& rnd ="? इसका क्या उद्देश्य है? इस टैग द्वारा हल की जाने वाली समस्याएं क्या हैं?

Answer 1

यह सुनिश्चित करने के लिए कि पृष्ठ/छवि/जो भी उपयोगकर्ता के कैश से नहीं लिया गया हो, यह सुनिश्चित किया जा सकता है। यदि लिंक हर बार अलग होता है तो ब्राउजर इसे कैश से बजाए सर्वर से प्राप्त करेगा, यह सुनिश्चित करेगा कि यह नवीनतम संस्करण है।

यह साइट के माध्यम से लोगों की प्रगति को ट्रैक करने के लिए भी हो सकता है। सर्वश्रेष्ठ कहानी के साथ सर्वश्रेष्ठ समझाया गया:

1. कोई उपयोगकर्ता example.com पर जाता है। सभी लिंक एक ही यादृच्छिक संख्या दिए जाते हैं (मान लें 4)।
2. उपयोगकर्ता एक नई विंडो/टैब में एक लिंक खोलता है, और लिंक page2.php? Rnd = 4 है। इस पृष्ठ के सभी लिंक यादृच्छिक संख्या 7 दिए गए हैं।
3. उपयोगकर्ता मूल टैब या पृष्ठ से पृष्ठ 3.php के लिंक पर क्लिक कर सकते हैं, और सर्वर पर एनालिटिक्स सॉफ़्टवेयर बता सकता है कि उसके पास कौन सा है आरएनडी = 4 या आरएनडी = 7।

हम जो कुछ भी कर सकते हैं वह संभावनाएं सुझाता है। यूआरएल में आरएनडी = डालने का कोई मानक कारण नहीं है, और हम सर्वर सॉफ़्टवेयर को देखे बिना वेबसाइट डिजाइनर के उद्देश्यों को नहीं जान सकते हैं।

Answer 2

यह लगभग हमेशा कैश-बस्टिंग के लिए है।

Answer 3

इंटरनेट एक्सप्लोरर और अन्य ब्राउज़र एक छवि यूआरएल पढ़ेंगे, छवि डाउनलोड करेंगे, और इसे कैश में स्टोर करेंगे।

यदि आपका एप्लिकेशन नियमित रूप से छवि को अपडेट करने जा रहा है, और इसलिए आप चाहते हैं कि आपके उपयोगकर्ता कैश की गई छवि न देखें, तो URL को हर बार अद्वितीय होना चाहिए।

इसलिए, एक यादृच्छिक स्ट्रिंग जोड़ना सुनिश्चित करता है कि यह प्रत्येक बार कैश में अद्वितीय और डाउनलोड होगा।

Answer 4

जैसा कि दूसरों द्वारा सुझाया गया है। इस प्रकार का व्यवहार आमतौर पर कैशिंग मुद्दों से बचने के लिए उपयोग किया जाता है जब आप एक पृष्ठ को कॉल कर रहे हैं जो गतिशील सामग्री डेटा देता है।

उदाहरण के लिए, कहें कि आपके पास एक ऐसा पृष्ठ है जो "mysite.com/CurrentUserData" जैसी कुछ मौजूदा उपयोगकर्ता जानकारी प्राप्त करता है। अब इस पृष्ठ के पहले कॉल पर, उपयोगकर्ता डेटा अपेक्षित के रूप में वापस कर दिया जाएगा, लेकिन समय और कैशिंग सेटिंग्स के आधार पर, दूसरी कॉल एक ही डेटा लौटा सकती है - भले ही अपेक्षित डेटा अपडेट हो गया हो।

कैशिंग के लिए मुख्य कारण लगातार अनुरोध की गति को अनुकूलित करने के लिए है। लेकिन उदाहरण में जहां यह नहीं चाहता था, एक क्वेरी स्ट्रिंग पैरामीटर के रूप में एक यादृच्छिक मान जोड़ना व्यापक रूप से उपयोग किया जाने वाला समाधान माना जाता है।

हालांकि इस मुद्दे को हल करने के अन्य तरीके हैं। उदाहरण के लिए यदि आप जावास्क्रिप्ट/JQuery के साथ एक अजाक्स अनुरोध कर रहे थे। आप अपने कॉल में कैश को झूठा सेट कर सकते हैं ...

$.ajax({url: 'page.html', cache: false}); 

आप इसे दस्तावेज़ लोड पर सभी पेज कॉल के लिए भी बदल सकते हैं ...

$.ajaxSetup({cache: false}}); 

आप एक MVC आवेदन करने के लिए थे, तो आप फिर भी जैसे एक विशेषता के साथ नियंत्रण कार्रवाई तरीकों पर कैशिंग निष्क्रिय कर सकते हैं ...

[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")] 
public ActionResult NonCacheableData() 
{ 
    return View(); 
} 

(एक त्वरित कॉपी और पेस्ट करने के लिए धन्यवाद here से)

मुझे लगता है कि आईआईएस में भी सेटिंग्स हैं जो आप एक ही प्रभाव प्राप्त करने के लिए आवेदन कर सकते हैं - हालांकि मैं अभी तक इस तक नहीं रहा हूं।