मैं jQuery के लिए तृतीय पक्ष jsonp लाइब्रेरी का उपयोग कर रहा हूं। इसे कॉल में, आप कैशे को सही पर सेट कर सकते हैं।

हालांकि, HTTP स्निफर में जांच करने पर, ऐसा प्रतीत होता है कि सभी अनुरोध अभी भी सर्वर पर भेजे जा रहे हैं।

यह पिकासा, फ़्लिकर और यूट्यूब एपीआई के साथ है।

इस व्यवहार का कारण क्या हो सकता है? यह ब्राउज़र-विशिष्ट प्रतीत नहीं होता है क्योंकि मैंने इसे कई ब्राउज़रों में परीक्षण किया है और सभी समान व्यवहार करते हैं (कैशिंग नहीं)।

बुलाए गए यूआरएल एक अनुरोध से दूसरे अनुरोध में नहीं बदलते हैं और कॉल इस तरह दिखता है:

        $.jsonp({
            url: url,
            cache: true,
            async: false,
            dataType: 'jsonp',
            data: $.extend({ url: options.dataUrl, method: lookupData.method }, fixedOptions),
            callbackParameter: "jsoncallback",
            success: function(data)
            {
                $.extend(datasourceOptions, lookupData.onData(data));
                getData();
            }
        });

मेरे सेटअप के बारे में एकमात्र "अजीब" बात यह है कि .jsonp को कॉल करने वाली स्क्रिप्ट को .ajax कॉल के माध्यम से ही शामिल किया जाता है .. क्या यह यहां मुद्दा हो सकता है? सुनने में अटपटा लगता है लेकिन...

धन्यवाद, वेस्ली

संपादित करें: ठीक है, 4 में से 3 के पास एक्सपायर हैडर सेट हैं..

हालांकि, चौथा नहीं है और केवल ये है:

कैश-नियंत्रण: निजी भिन्न: स्वीकार-एन्कोडिंग पहुंच-नियंत्रण-अनुमति दें-उत्पत्ति: * कनेक्शन: बंद करें

(यह फ़्लिकर है)

वहाँ क्या हो रहा है?

साथ ही, क्या किसी भी तरह jQuery के माध्यम से हेडर कैशिंग निर्देशों को ओवरराइड करना संभव नहीं है?

0
user429620 26 जुलाई 2011, 10:48
"मैं jQuery के लिए थर्ड पार्टी jsonp लाइब्रेरी का उपयोग कर रहा हूं। इसे कॉल करने के लिए, आप कैशे को सही पर सेट कर सकते हैं।" यदि इसका उपयोग करने का आपका एकमात्र कारण है, तो आप jQuery के बिल्ट-इन का उपयोग कर सकते हैं JSONP हैंडलिंग, जो आपको cache: true को दस्तावेज़ के अनुसार सेट करने देती है। जाहिर है अगर आपके पास प्लग-इन, फेयर 'नफ का उपयोग करने का कोई अन्य कारण है, लेकिन ऐसा लगता है कि आपको कैशिंग की आवश्यकता है।
 – 
T.J. Crowder
26 जुलाई 2011, 10:57
नहीं नहीं, मुझे इसके लिए एक और आवश्यकता है, अर्थात् बेहतर त्रुटि प्रबंधन।
 – 
user429620
26 जुलाई 2011, 10:58

1 उत्तर

सबसे बढ़िया उत्तर

मैं उम्मीद करता हूं कि जिन सेवाओं को आप कॉल कर रहे हैं वे कैश कंट्रोल हेडर लौटा रहे हैं जो ब्राउज़र को प्रतिक्रिया को कैश नहीं करने के लिए कहते हैं/कैश्ड प्रतिक्रिया को बहुत जल्दी समाप्त करने के लिए कहते हैं। आपको उन्हें HTTP संदेशों में देखने में सक्षम होना चाहिए। उस तरह की चीज़ Cache-Control और/या Expires को देखें।

अपना संपादन पुनः करें:

साथ ही, क्या किसी भी तरह jQuery के माध्यम से हेडर कैशिंग निर्देशों को ओवरराइड करना संभव नहीं है?

मुझे ऐसा नहीं लगता, नहीं, निश्चित रूप से JSON-P के साथ नहीं, जो इसके दिल में एक script तत्व है जिसे पृष्ठ में जोड़ा जा रहा है, इसलिए उस पर प्रोग्रामेटिक नियंत्रण बेहद सीमित होने वाला है। यहां तक ​​​​कि अगर यह एक्सएचआर था, तो स्पष्ट रूप से, मुझे नहीं लगता कि ब्राउज़र को कैश किए गए संस्करण का उपयोग करने के लिए कहने का कोई तरीका है जो इसके स्रोत के अनुसार पुराना है।

यदि यह पृष्ठ जीवनचक्र के भीतर हो रहा है, तो आप पृष्ठ पर किसी ऑब्जेक्ट में परिणाम को स्वयं कैश कर सकते हैं, लेकिन मुझे लगता है कि आप पृष्ठ पर विज़िट के बीच कैशिंग के बारे में बात कर रहे हैं (हालांकि मैं तुरंत नहीं देख सकता कि आप क्यों चाहते हैं ताजा/बासी की उत्पत्ति की परिभाषा को हराएं)।

1
T.J. Crowder 26 जुलाई 2011, 11:06
हालांकि, किसी के पास केवल कैश-कंट्रोल है: निजी फिर भी इसे कैश नहीं किया जा रहा है।
 – 
user429620
26 जुलाई 2011, 10:56
@Wesley: private = "यह दर्शाता है कि प्रतिक्रिया संदेश का पूरा या कुछ हिस्सा एकल उपयोगकर्ता के लिए है और साझा कैश द्वारा कैश नहीं किया जाना चाहिए।" (reference) मुझे आश्चर्य नहीं होगा अगर ब्राउज़र इसे गैर- कैश करने योग्य
 – 
T.J. Crowder
26 जुलाई 2011, 10:58
जो मैंने सोचा था कि इसका मतलब होगा कि अंतिम उपयोगकर्ता इसे कैश कर सकता है, लेकिन एक प्रॉक्सी नहीं कर सकता। मैं एक अंतिम उपयोगकर्ता हूं और यह कैश नहीं करता है।
 – 
user429620
26 जुलाई 2011, 11:00
@ वेस्ले: ठीक है, जाहिर है कि ब्राउज़र इसे गैर-कैश करने योग्य मान रहा है, जैसा कि आप देख रहे हैं कि इसे कैश नहीं किया जा रहा है।
 – 
T.J. Crowder
26 जुलाई 2011, 11:02