caching - उन छवियों के लिए HTTP अनुरोध करने के लिए ब्राउज़र बंद करें जिन्हें कैश रहना चाहिए - mod_expires

Translate

यहाँ पर कई लेख और कुछ प्रश्न पढ़ने के बाद,मैं आखिरकार अपाचे को सक्रिय करने में सफल हो गयाmod_expiresब्राउज़र को यह बताने के लिए कि उसे 1 वर्ष के लिए कैश इमेज चाहिए.

<filesMatch "\.(ico|gif|jpg|png)$">
  ExpiresActive On
  ExpiresDefault "access plus 1 year"
  Header append Cache-Control "public"
</filesMatch>

और शुक्र है कि सर्वर प्रतिक्रियाएँ सही प्रतीत होती हैं:

HTTP/1.1 200 OK 
Date: Fri, 06 Apr 2012 19:25:30 GMT 
Server: Apache 
Last-Modified: Tue, 26 Jul 2011 18:50:14 GMT 
Accept-Ranges: bytes 
Content-Length: 24884 
Cache-Control: max-age=31536000, public 
Expires: Sat, 06 Apr 2013 19:25:30 GMT
Connection: close
Content-Type: image/jpeg

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

मैं प्रत्येक छवि के लिए HTTP अनुरोध करने से रोकने के लिए ब्राउज़र को कैसे बाध्य करूं? भले ही इन HTTP अनुरोधों को डाउनलोड की जा रही छवि के बाद नहीं किया जाता है, फिर भी वे सर्वर से किए गए अनुरोध हैंकि अनावश्यक रूप से विलंबता विलंबित और पृष्ठ प्रतिपादन धीमा!

मैंने पहले ही ब्राउज़र को बता दिया था कि चित्र को 1 वर्ष के लिए कैश में रखना होगा! क्यों ब्राउज़र अभी भी प्रत्येक छवि के लिए सर्वर से पूछताछ करता है (भले ही वह छवि को डाउनलोड न करे) ?!

फायरबग (मेनू फ़ायरबग> नेट> इमेजेज) में नेटवर्क ग्राफ़ को देखते हुए मैं अलग-अलग कैशिंग व्यवहार देख सकता हूं (मैं स्पष्ट रूप से ब्राउज़र कैश के साथ शुरू हुआ था, पूरी तरह से खाली, मैंने "क्लियर ऑल हिस्ट्री" का उपयोग करके ब्राउज़र पर कैश डिलीट करने के लिए मजबूर किया):

  • जब पृष्ठ को पहली बार लोड किया जाता है तो सभी चित्र डाउनलोड हो जाते हैं(और यही बात होती है यदि मैं ब्राउज़र के पेज लोड करने के बटन पर क्लिक करके पृष्ठ को फिर से लोड करता हूं)।यह समझ में आता है!

  • जब मैं साइट को नेविगेट करता हूं और उसी पृष्ठ पर वापस जाता हूंचित्र बिल्कुल डाउनलोड नहीं हैं औरब्राउज़र सर्वर से पूछताछ भी नहीं करता हैकिसी भी चित्र के लिए।यह समझ में आता है, (और मैं इस व्यवहार को भी देखना चाहता हूं जब ब्राउज़र बंद हो जाता है)!

  • जब मैं ब्राउज़र को बंद करता हूं और फिर से उसी पृष्ठ पर खोलता हूं, तो मूर्ख ब्राउज़र वैसे भी सर्वर से प्रति बार एक बार HTTP अनुरोध करता है: यह छवि को डाउनलैड नहीं करता है, लेकिन यह अभी भी एक HTTP अनुरोध करता है, यह ब्राउज़र की तरह है। छवि के बारे में सर्वर(सर्वर 200 ओके के साथ जवाब देता है)।यह वह है जो मुझे परेशान करता है!

यदि आप रुचि रखते हैं तो मैं नीचे दिए गए ग्राफ़ को भी संलग्न करता हूं:

enter image description here

enter image description here

संपादित करें: अभी अभी फायरफॉक्स 11.0 के साथ भी परीक्षण किया गया है ताकि यह सुनिश्चित हो सके कि यह मेरे फायरफॉक्स 3.6 का मुद्दा नहीं था। वही होता है !!!मैंने Google साइट और Stackoverflow साइट का भी परीक्षण किया, वे दोनों भेजते हैंCache-Control: max-age=...परंतुब्राउज़र बंद होने और फिर से एक ही पृष्ठ पर खोले जाने के बाद भी ब्राउज़र प्रत्येक छवि के लिए सर्वर से HTTP अनुरोध करता है, सर्वर प्रतिक्रिया के बाद ब्राउज़र छवि को डाउनलोड नहीं करता है (जैसा कि मैंने ऊपर बताया गया है) लेकिन यह अभी भी लानत अनुरोध करता है जो पृष्ठ देखने के लिए समय बढ़ाता है।

EDIT2: और निकाल रहा हैLast-Modifiedसुझाव के अनुसार हैडरयहाँ, समस्या को हल नहीं करता है, इससे कोई फर्क नहीं पड़ता है।

स्रोत
This question and all comments follow the "Attribution Required."

सभी उत्तर

Oliver Kurmis
Translate

आप अनुरोधों के विश्लेषण के लिए गलत टूल का उपयोग कर रहे थे।

मैं वास्तव में उपयोगी फ़ायरफ़ॉक्स addon की सिफारिश करेंगेलाइव HTTP हेडरतो आप देख सकते हैं कि वास्तव में नेटवर्क पर क्या चल रहा है।

और बस सुनिश्चित करने के लिए, आप अपने सर्वर को ssh / putty कर सकते हैं और कुछ ऐसा कर सकते हैं

tail -f /var/log/apache2/access.log
स्रोत
Jason Buberel
Translate

जो व्यवहार आप देख रहे हैं, वह इरादा है (देखें)RFC7234अधिक जानकारी के लिए), निर्दिष्ट व्यवहार:

सभी आधुनिक ब्राउज़र कैश की स्थिति की परवाह किए बिना, प्रत्येक पृष्ठ तत्व के लिए सर्वर पर HTTP अनुरोध भेजेंगे। यह वेब सेवाओं (विशेषकर विज्ञापन नेटवर्क) के अनुरोध पर किया गया एक डिज़ाइन निर्णय था जो यह सुनिश्चित करने के लिए था कि HTTP सर्वर हर तत्व के हर प्रदर्शन के रिकॉर्ड को बनाए रखने में सक्षम थे।

यदि ब्राउज़र ने ये अनुरोध नहीं किया है, तो सर्वर को कभी सूचित नहीं किया जाएगा कि उपयोगकर्ता को एक छवि प्रदर्शित की गई थी। विज्ञापन नेटवर्क के लिए, यह विनाशकारी होगा। आरंभ में, विज्ञापन नेटवर्क ने बेतरतीब ढंग से उत्पन्न नामों (उदा: 'coke_ad_1_98719283719283.gif') का उपयोग करके उसी विज्ञापन छवि की सेवा करके इसके चारों ओर अपना रास्ता 'हैक' कर लिया। हालाँकि, ISPs के लिए इस अभ्यास के कारण डेटा ट्रांसफ़र में भारी वृद्धि हुई, क्योंकि उनके हर एक उपयोगकर्ता इन समान विज्ञापन छवियों को फिर से डाउनलोड कर रहे थे, किसी भी कैशिंग / प्रॉक्सी सर्वर को दरकिनार करते हुए उनका ISP संचालन कर रहा था।

तो एक समस्या पैदा हो गई थी: ब्राउज़र हमेशा HTTP अनुरोध भेजेंगे, यहां तक कि अन-एक्‍सपायर्ड कैशेड तत्‍वों के लिए भी। सर्वर HTTP 304 स्थिति कोड ("संशोधित नहीं") के साथ जवाब देंगे। यह सर्वर को इस तथ्य को रिकॉर्ड करने की अनुमति देता है कि छवि क्लाइंट को प्रदर्शित की गई थी। परिणामस्वरूप, विज्ञापन नेटवर्कआम तौर परनेटवर्क कैश सर्वर को बायपास करने के लिए यादृच्छिक छवि नामों का उपयोग करना बंद कर दिया।

इसने विज्ञापन नेटवर्क को वह दिया जो वे चाहते थे - प्रदर्शित हर छवि का एक रिकॉर्ड - और इसने आईएसपी को वह दिया जो वे चाहते थे - कैश-सक्षम छवियां और स्थिर सामग्री।

यही कारण है कि कैश्ड पेज तत्वों के लिए HTTP अनुरोध भेजने से ब्राउज़र को रोकने के लिए आप बहुत कुछ नहीं कर सकते हैं।

लेकिन अगर आप एचटीएमएल 5 के साथ आए अन्य उपलब्ध क्लाइंट-साइड समाधानों को देखते हैं, तो संसाधन लोडिंग को रोकने की गुंजाइश है

  1. कैश मेनीफेस्ट(इसके गोश्त के बावजूद)
  2. IndexedDB(अच्छा अतुल्यकालिक सुविधाएँ, बूँद भंडारण की अनुमति देता है)
  3. स्थानीय भंडार(async नहीं)
स्रोत
chugadie
Translate

"रीलोडिंग" और "रिफ्रेशिंग" के बीच अंतर है। बस बैक और फॉरवर्ड बटन वाले पेज पर नेविगेट करना आमतौर पर नए HTTP अनुरोधों को शुरू नहीं करता है, लेकिन विशेष रूप से पृष्ठ को "रीफ़्रेश" करने के लिए F5 को हिट करने से ब्राउज़र को अपने कैश को दोबारा जांचना होगा। यह ब्राउज़र पर निर्भर है लेकिन लगता है कि FF और Chrome (यानी वे ब्राउज़र जो अपने नेटवर्क ट्रैफ़िक को आसानी से देखने की क्षमता रखते हैं) के लिए मानदंड हैं। F6 को हिट करते हुए, URL एड्रेस बार पर ध्यान केंद्रित करना चाहिए और फिर इसे "जाना" चाहिए, जो कि करना चाहिए पृष्ठ को फिर से लोड करें लेकिन पृष्ठ पर संपत्ति की दोहरी जांच न करें।

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

यदि आप अपने डेवलपर नेटवर्क पैनल में (200 OK BFCache) देखते हैं, तो सर्वर कभी हिट नहीं हुआ था - यहां तक कि यह पूछने के लिए कि क्या संशोधित किया गया है।

http://www.softwareishard.com/blog/firebug/firebug-tip-what-the-heck-is-bfxache/

स्रोत
Peter Lundsby
Translate

अगर मैं F5 या F5 + Ctrl का उपयोग करके रिफ्रेश को बाध्य करता हूं, तो एक अनुरोध भेजा जाता है। हालाँकि अगर मैं ब्राउज़र को बंद करता हूं और फिर से url दर्ज करता हूं तो NO reeeust भेजा जाता है। जिस तरह से मैंने अनुरोध किया है कि क्या एक अनुरोध भेजा गया है या नहीं, तब भी सर्वर पर शुरू अनुरोध पर ब्रेकपॉइंट का उपयोग करने से तब भी जब एक अनुरोध नहीं भेजा जाता है, यह अभी भी फायरबग में दिखाता है जैसा कि 7 एमएस प्रतीक्षा किया गया है, इसलिए इससे सावधान रहें।

स्रोत
symcbean
Translate

आप यहाँ जो वर्णन कर रहे हैं वह मेरे अनुभव को नहीं दर्शाता है। यदि सामग्री को बिना स्टोर के निर्देश के साथ परोसा जाता है या आप एक स्पष्ट रिफ्रेश करते हैं, तो हां, मैं यह उम्मीद करूंगा कि यह मूल सर्वर पर वापस जाए अन्यथा इसे ब्राउज़र रीस्टार्ट में कैश किया जाना चाहिए (यह मानते हुए कि इसे अनुमति दी गई है, और लिख सकते हैं एक कैश फ़ाइल)।

अपने जलप्रपातों को थोड़ा और विस्तार से देखें (जो कि मुश्किल है क्योंकि वे थोड़े छोटे और धुंधले हैं) ब्राउज़र बिल्कुल वैसा ही प्रतीत होता है जैसा कि इसे करना चाहिए - यहहैछवियों के लिए प्रविष्टियाँ - लेकिन ये सिर्फ लोड हो रही हैंस्थानीय कैश सेमूल सर्वर से नहीं - प्रतिक्रिया में 'दिनांक' शीर्ष लेख देखें (आपको ऐसा क्यों लगता है कि यह सेकंड के बजाय मिलीसेकंड ले रहा है?)। इसलिए वे अलग-अलग रंग के होते हैं।

स्रोत
dev-vb
Translate

अपने आप को एक उचित उत्तर की तलाश में काफी समय बिताने के बाद, मुझे नीचे दिया गया लिंक सबसे उपयोगी लगा और यह यहाँ पूछे गए प्रश्न का उत्तर देता है।

https://webmasters.stackexchange.com/questions/25342/headers-to-prevent-304-if-modified-since-head-requests

स्रोत
djeendo
Translate

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

HTML5 का उपयोग करेंस्थानीय भंडारपहली बार अनुरोध करने के बाद छवियों को कैश करने के लिए।

  • [+]आप ब्राउज़र को HTTP अनुरोध भेजने से रोक सकते हैं, जो 99% में 304 (संशोधित नहीं) लौटाएगा, चाहे उपयोगकर्ता कितनी भी कोशिश कर ले (F5, ctrl + F5, बस पृष्ठ को फिर से देखना आदि)।

  • [-]आपको इसके लिए जावास्क्रिप्ट समर्थन में कुछ अतिरिक्त प्रयास करने होंगे।

  • [-]छवियां बेस 64 में संग्रहीत की जाती हैं (हम बाइनरी डेटा स्टोर नहीं कर सकते हैं), यही कारण है कि उन्हें क्लाइंट साइड पर हर बार डिकोड किया जाता है। जो हैआमतौर परबहुत तेज़ और बड़ी बात नहीं है, लेकिन यह अभी भी ग्राहक की ओर से कुछ अतिरिक्त सीपीयू उपयोग है और इसे ध्यान में रखा जाना चाहिए।

  • [-]स्थानीय भंडारण सीमित है। आप प्रति डोमेन ~ 5mb डेटा का उपयोग करने के लिए लक्ष्य कर सकते हैं (नोट: base64 छवि के मूल आकार में ~ 30% जोड़ता है)।

  • [?]द्वारा समर्थितबहुमतब्राउज़रों की।http://caniuse.com/#search=localstorage

उदाहरण

परीक्षा

स्रोत
wharding28
Translate

Chrome में आप जो देख रहे हैं वह वास्तविक HTTP अनुरोधों का रिकॉर्ड नहीं है - यह संपत्ति अनुरोधों का रिकॉर्ड है। Chrome आपको यह दिखाने के लिए करता है कि वास्तव में पृष्ठ द्वारा किसी संपत्ति का अनुरोध किया जा रहा है। हालाँकि, यह दृश्य वास्तव में इंगित नहीं करता है कि क्या अनुरोध किया जा रहा है। यदि कोई संपत्ति कैश की जाती है, तो क्रोम वास्तव में अंतर्निहित HTTP अनुरोध कभी नहीं बनाएगा।

आप समय-सीमा में बैंगनी खंडों पर मंडराते हुए भी इसकी पुष्टि कर सकते हैं। कैश्ड संसाधनों में एक होगा(from cache)टूलटिप में।

वास्तविक HTTP अनुरोधों को देखने के लिए, आपको निचले स्तर पर देखने की आवश्यकता है। कुछ ब्राउज़रों में यह एक प्लगइन (जैसे लाइव HTTP हेडर) के साथ किया जा सकता है।

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

स्रोत
Rakesh
Translate

कैश सत्यापन और 304 प्रतिक्रिया

ऐसी कई स्थितियाँ हैं जिनमें Internet Explorer को यह जाँचने की आवश्यकता है कि क्या कैश्ड प्रविष्टि मान्य है:

  • कैश्ड प्रविष्टि की कोई समाप्ति तिथि नहीं है और ब्राउज़र सत्र में पहली बार सामग्री को एक्सेस किया जा रहा है

  • कैश्ड प्रविष्टि की समाप्ति तिथि है लेकिन यह समाप्त हो गई है

  • उपयोगकर्ता ने ताज़ा बटन पर क्लिक करके या F5 दबाकर एक पेज अपडेट का अनुरोध किया है

यदि कैश्ड प्रविष्टि में एक अंतिम संशोधन तिथि है, तो IE इसे GET अनुरोध संदेश के आईएफ-संशोधित-चूंकि हेडर में भेजता है:

GET /images/logo.gif HTTP/1.1
Accept: */*
Referer: http://www.google.com/
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 23 Sep 2004 17:42:04 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)
Host: www.google.com

सर्वर इफ़-मॉडिफाइड-चूंकि हेडर की जाँच करता है और तदनुसार प्रतिक्रिया करता है। यदि दिनांक / समय निर्दिष्ट होने के बाद से सामग्री नहीं बदली गई है, तो वह 304 की स्थिति कोड और एक प्रतिक्रिया संदेश के साथ उत्तर देता है जिसमें केवल हेडर शामिल हैं:

HTTP/1.1 304 Not Modified
Content-Type: text/html
Server: GWS/2.1
Content-Length: 0
Date: Thu, 04 Oct 2004 12:00:00 GMT

प्रतिक्रिया को जल्दी से डाउनलोड किया जा सकता है क्योंकि इसमें कोई सामग्री नहीं है और IE को कैश से इसके लिए आवश्यक डेटा पढ़ने का कारण बनता है। वास्तव में, यह स्थानीय ब्राउज़र कैश के पुनर्निर्देशन की तरह है।

यदि अनुरोधित वस्तु वास्तव में आईएफ-संशोधित-हेडर में दिनांक / समय के बाद से बदल गई है, तो सर्वर 200 की स्थिति कोड के साथ प्रतिक्रिया करता है और संसाधन के संशोधित संस्करण की आपूर्ति करता है।

स्रोत
sandeepkunkunuru
Translate

इस सवाल का बेहतर जवाब हैयहाँवेबमास्टर्स स्टैक-एक्सचेंज साइट पर।

अधिक जानकारी, जो उपरोक्त लिंक में भी उद्धृत है, चालू हैhttpwatch

लेख के अनुसार:

ऐसी कई स्थितियाँ हैं जिनमें Internet Explorer को यह जाँचने की आवश्यकता है कि क्या कैश्ड प्रविष्टि मान्य है:

  • कैश्ड प्रविष्टि की कोई समाप्ति तिथि नहीं है और ब्राउज़र सत्र में पहली बार सामग्री को एक्सेस किया जा रहा है
  • कैश्ड प्रविष्टि की समाप्ति तिथि है लेकिन यह समाप्त हो गई है

  • उपयोगकर्ता ने ताज़ा बटन पर क्लिक करके या F5 दबाकर एक पेज अपडेट का अनुरोध किया है

    यहाँ कोड दर्ज करें

स्रोत
Leave a Reply
You must be logged in to post a answer.
लेखक के बारे में
Marco Demaio
EN (English) CN (简体中文) RU (Русский) IN (हिन्दी) PL (język polski) HU (Magyar) JP (日本語) FR (Français) CZ (čeština) IT (italiano) BG (български) DE (Deutsche) FI (Suomalainen) PT (Português)
इसी तरह की समस्याएं
Category