क्या फ़ायरफ़ॉक्स जावास्क्रिप्ट को कैश करता है और पथ में क्वेरीस्ट्रिंग होने पर अनुरोध के बिना इसका उपयोग करता है?

Question

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

जिस तरह से मैं इसे PHP में पूरा कर रहा हूं वह सीवीएस टैग से पढ़ना है। जब मैं उत्पादन करने के लिए HTML का निर्माण कर रहा हूँ, मैं सीवीएस टैग पढ़ सकते हैं और उपयोग करें कि जावास्क्रिप्ट पथ के अंत करने के लिए संलग्न करने के लिए इतना है कि यह एक स्क्रिप्ट टैग है कि इस तरह दिखता है बनाता है: एप्लिकेशन के रूप में

<script src="javascript/messages/shipments.js?TPRSAPPS-DEV2_090828145712237-BRANCH" type="text/javascript"></script> 

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

यह IE8 में बहुत अच्छा काम करता है। मेरी समस्या फ़ायरफ़ॉक्स के साथ है। फ़ायरफ़ॉक्स फाइलों को कैश करता है, लेकिन अगली बार जब मैं पेज लोड करता हूं फायरबग 304 प्रतिक्रिया दिखाता है, यह दर्शाता है कि यह अभी भी फ़ाइल के लिए नेटवर्क अनुरोध करता है और फिर पाया कि यह नहीं बदला है।

तो मेरा सवाल यह है कि, फ़ायरफ़ॉक्स एक क्वेरी स्ट्रिंग होने पर जावास्क्रिप्ट की समाप्ति शीर्षलेख और कैश को अनदेखा करता है?

संबंधित: what does firefox decide not to cache? जाहिर है रेल कुछ समान करता है। लेकिन यह मेरे प्रश्न का उत्तर नहीं देता है।

https://appdev.prsx.net/~jhargett/PRSApps-Motorlog/javascript/menuReader.js?TPRSAPPS-DEV2_090828145712237-BRANCH-DIFFERENT 

HTTP/1.1 304 Not Modified 
Date: Mon, 03 Oct 2011 18:35:26 GMT 
Server: Apache/2.2.3 (Red Hat) 
Connection: close 
Etag: "179010-3f8-49a9a74334200" 
Vary: Accept-Encoding 

Firebug में कैश टैब का कहना है::

यहाँ प्रतिक्रिया मैं इस फ़ाइल पर वापस हो रही है है

Last Modified Mon Oct 03 2011 13:35:26 GMT-0500 (Central Daylight Time) 
Last Fetched Mon Oct 03 2011 13:35:26 GMT-0500 (Central Daylight Time) 
Expires Fri Oct 28 2011 18:33:31 GMT-0500 (Central Daylight Time) 
Data Size 345 
Fetch Count 12 
Device disk 

Answer 1

तर्क फ़ायरफ़ॉक्स कैश्ड प्रतिक्रिया दी एक सशर्त प्राप्त करने के लिए तय करने के लिए उपयोग करता

इसलिए की तरह है:

1. अगर वहाँ एक प्रासंगिक है हैडर वैरी, दोबारा सत्यापित।
2. यदि यह अनुरोध कैश से बलपूर्वक लोड किया जाना चाहिए, तो पुन: सत्यापित न करें।
3. यदि इस अनुरोध में "हमेशा मान्य" ध्वज है, तो पुनः सत्यापित करें।
4. यदि इस अनुरोध में "कभी मान्य नहीं" ध्वज है तो केवल तभी पुनरीक्षित करें यदि यह नो-स्टोर प्रतिक्रिया या SSL नो-कैश प्रतिक्रिया है।
5. यदि प्रतिक्रिया स्थिति कोड कैश करने योग्य नहीं है या प्रतिक्रिया नो-कैश या नो-स्टोर है या यदि समाप्ति समय प्रतिक्रिया की तारीख से पहले है, तो पुनः सत्यापित करें।
6. यदि कोई प्रश्न पैरामीटर है और प्रतिक्रिया में कोई स्पष्ट समाप्ति या अधिकतम आयु नहीं है, तो पुनः सत्यापित करें।
7. यदि प्रतिक्रिया समाप्ति समय अतीत में है, तो पुन: सत्यापित करें (जब तक "प्रति सत्र उपयोगकर्ता वरीयता सेट पर केवल एक बार फिर से सत्यापित नहीं किया जाता")।

तो आपके मामले के लिए, एक सशर्त जीईटी नहीं होना चाहिए, मान लीजिए कि आप वास्तव में अपने 200 प्रतिक्रिया पर समाप्ति या अधिकतम आयु की जानकारी निर्धारित करते हैं।

यह कहा गया है कि फ़ायरफ़ॉक्स के लिए HTTP जानकारी का पता लगाने का प्रयास करने वाले कुछ टूल वास्तव में पुनर्मूल्यांकन व्यवहार को प्रभावित करते हैं, इसलिए आप इसमें भाग ले सकते हैं।

मैं https://developer.mozilla.org/en/HTTP_Logging में दिए चरणों का जो संयोग से आपको बता देंगे निम्नलिखित एक लॉग बनाने की सलाह देते वास्तव में क्यों एक सशर्त प्राप्त किया जा रहा है, आप लॉग का सही हिस्सा मिल सकता है (के लिए खोज "nsHttpChannel :: CheckCache प्रवेश के लिए" उपर्युक्त तर्क लागू करने वाले फ़ंक्शन से लॉगिंग)।

Answer 2

क्या आप देख रहे हैं कुछ वास्तव में फ़ाइल डाउनलोड करने से अलग है , और फिर कहें कि यह नहीं बदला है।

फ़ायरफ़ॉक्स फ़ाइल जानकारी प्राप्त करने के लिए HTTP अनुरोध करता है, न कि फ़ाइल स्वयं। इसका मतलब है कि फ़ायरफ़ॉक्स यह चालाक कर रहा है तो आईई कर रहा है।

अनुरोध फ़ायरफ़ॉक्स केवल बाइट्स (फाइलसाइज, दिनांक इत्यादि) के कुछ जोड़े हैं। तो कोई फर्क नहीं पड़ता कि नाम क्या है, फ़ायरफ़ॉक्स इसे कैश करता है (जब तक अक्षम नहीं)। अगर फ़ाइल स्वयं बदलती है, तो फ़ायरफ़ॉक्स फ़ाइल को फिर से डाउनलोड करने का निर्णय लेता है।

जो चीज आप इंगित कर रहे हैं वह वास्तव में सही व्यवहार है।

Answer 3

यदि आप पूरी तरह से सुनिश्चित होना चाहते हैं कि आपकी फ़ाइल पुनः लोड हो जाएगी, तो फ़ाइल नाम में संस्करण संख्या/कैश बस्टर स्ट्रिंग को सीधे रखना बेहतर होगा। तो आपके पास shipments_v2.js या shipments_(unix_timestamp).js जैसी कुछ होगी। यह प्रॉक्सी और किसी अन्य प्रकार की कैशिंग तंत्र का ख्याल रखेगा।

Answer 4

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

sub vcl_recv { 
    [..] 
     if (req.url ~ "\?v=\w+$") { 
      set req.http.X-Versioned = "1"; 
     } 
    [..] 
    } 

    sub vcl_deliver { 
    [..] 
     if (req.http.X-Versioned) { 
      unset resp.http.Etag; 
     } 
    [..] 
    }