HTTP शीर्षलेख: कैश और इतिहास तंत्र को नियंत्रित करना

Question

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

स्टेटिक सार्वजनिक सामग्री

सभी "स्टैटिक सार्वजनिक सामग्री" सामान जो HTTP वास्तव में सभी के बारे में है: यदि URL एक ही है, सामग्री एक ही है। मैं इसे आसानी से कर सकता हूं: उदाहरण के लिए, मैंने उपयोगकर्ता प्रोफ़ाइल आइकन को http://domain.com/profiles/xyz/icon/1234abcd में रखा है जहां "1234abcd" आइकन की फ़ाइल सामग्री का SHA-1 है। यदि मैं भविष्य में आइकन में बदलता हूं, तो मैं एक नया यूआरएल बनाउंगा और सभी मौजूदा रेफरर्स को संशोधित करूँगा जो नए आइकन का उपयोग करना चाहिए। यह घोषणा करने के लिए सबसे अच्छे हेडर क्या हैं कि इसे हमेशा के लिए कैश किया जा सकता है और साझा किया जा सकता है? मैं वर्तमान में लाइनों के साथ कुछ सोच रहा हूं:

Date: <current time> 
Expires: <current time + one year> 

क्या यह उपयोगकर्ता एजेंटों और प्रॉक्सी द्वारा कैशिंग की अनुमति देने के लिए पर्याप्त है? क्या मुझे Last-Modified या Pragma की आवश्यकता है?

स्टेटिक गैर-सार्वजनिक सामग्री

सभी "स्टैटिक गैर-सार्वजनिक सामग्री" सामान है कि स्थिर है, लेकिन सभी को उपलब्ध नहीं हो सकता है। वास्तव में, यह सामग्री केवल चयनित लॉग इन उपयोगकर्ताओं के लिए उपलब्ध होगी (सत्र सत्र कुकी होल्डिंग सत्र यूयूआईडी के साथ रखा जाता है)। यदि यूआरएल समान है, तो सामग्री वही है। हालांकि, प्रतिक्रिया सार्वजनिक नहीं है। एक सोशल नेटवर्क सेवा में चयनित मित्रों को साझा किया गया एक छवि एक छवि हो सकती है। मैं वर्तमान में लाइनों के साथ कुछ सोच रहा हूं:

Date: <current time> 
Expires: <current time> 
Cache-Control: private, max-age=<huge number>, s-maxage=0 

क्या यह उपयोगकर्ता एजेंटों द्वारा कैशिंग को अनुमति देने और प्रॉक्सी अक्षम करने के लिए पर्याप्त है? क्या मुझे Pragma चाहिए?

वाष्पशील सार्वजनिक सामग्री

सभी "वाष्पशील सार्वजनिक सामग्री" सामान है कि अस्थिर और सभी को उपलब्ध है। लॉग इन नहीं होने पर http://slashdot.org/ के फ्रंट पेज की तरह कुछ। इरादा एक गैर-बदलते यूआरएल में सामग्री को तेजी से अद्यतन करने की अनुमति देना है। ध्यान दें कि मैं उपयोगकर्ता एजेंट इतिहास तंत्र (यानी, अस्थिर पृष्ठ से कुछ क्लिक करना और फिर बैक बटन को मारना नहीं चाहता, परिणामस्वरूप सर्वर से अस्थिर पृष्ठ लाने में परिणाम नहीं देना चाहिए - हालांकि, उस लिंक पर क्लिक करना सामने वाले पृष्ठ पर जाता है सर्वर से संसाधन लाने के लिए)। मैं वर्तमान में पंक्तियों के साथ कुछ सोच रहा हूँ:

Date: <current time> 
Expires: <current time> 
Cache-Control: public, max-age=0, s-maxage=0 

कैशिंग को रोकने के लिए, लेकिन इतिहास तंत्र (वापस बटन) की अनुमति के लिए यह पर्याप्त है? मुझे पता है कि अगर मैं Cache-Control: no-store, must-revalidate भेजता हूं तो मैं पुनः लोडिंग को मजबूर कर सकता हूं लेकिन यह वही नहीं है जो मैं चाहता हूं क्योंकि वह बैक बटन भी तोड़ देगा। क्या मुझे Last-Modified या Pragma की आवश्यकता है?

भले ही यह सार्वजनिक है, शायद यह मध्यस्थ प्रॉक्सी को कैश करने की अनुमति देने के लिए समझ में नहीं आता है क्योंकि यह अस्थिर है।

वाष्पशील गैर-सार्वजनिक सामग्री

सभी "वाष्पशील गैर-सार्वजनिक सामग्री" सामान है कि अस्थिर और सब लोग (निजी) के लिए नहीं उपलब्ध है। जब आप लॉग इन होते हैं तो http://slashdot.org/ के फ्रंट पेज की तरह कुछ। इरादा एक गैर-बदलते यूआरएल में सामग्री को तेजी से अद्यतन करने की अनुमति देना है। ध्यान दें कि मैं उपयोगकर्ता एजेंट इतिहास तंत्र (यानी, अस्थिर पृष्ठ से कुछ क्लिक करना और फिर बैक बटन को मारना नहीं चाहता, परिणामस्वरूप सर्वर से अस्थिर पृष्ठ लाने में परिणाम नहीं देना चाहिए - हालांकि, उस लिंक पर क्लिक करना सामने वाले पृष्ठ पर जाता है सर्वर से संसाधन लाने के लिए)। मैं वर्तमान में पंक्तियों के साथ कुछ सोच रहा हूँ:

Date: <current time> 
Expires: <current time> 
Cache-Control: private, max-age=0, s-maxage=0 

कैशिंग को रोकने के लिए, लेकिन इतिहास तंत्र (वापस बटन) की अनुमति के लिए यह पर्याप्त है? क्या मुझे Pragma चाहिए?

---

हालात अभी भी मेरे द्वारा सुझाए गए हेडर के साथ परीक्षण की जरूरत है कि:

• सत्यापित करें कि निजी सामग्री HTTP/1.0 प्रॉक्सी के माध्यम से लीक नहीं किया जाएगा।
• सत्यापित करें कि कैशिंग प्रॉक्सी में सही ढंग से काम करता है।
• सत्यापित करें कि कैशिंग उपयोगकर्ता एजेंटों में सही तरीके से काम करती है।
• सत्यापित करें कि उपयोगकर्ता एजेंट इतिहास तंत्र उपयोगकर्ता एजेंटों (सभी मामलों) में काम करता है।
• सत्यापित करें कि एक अस्थिर पृष्ठ के लिंक के बाद सर्वर से ताजा सामग्री प्राप्त होती है।
• HTTP के बजाय HTTPS का उपयोग करते समय सभी परिणामों को सत्यापित करें।

Answer 1

मैं जवाब देंगे मेरी ही सवाल:

स्टेटिक सार्वजनिक सामग्री

Date: <current time> 
Expires: <current time + one year> 

दलील: इस HTTP/1.0 प्रॉक्सी और RFC 2616 धारा 14 के साथ संगत है: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21 012,351,Last-Modified सही कैशिंग के लिए हेडर की आवश्यकता नहीं है (क्योंकि उपयोगकर्ता एजेंट अनुरूप Expires शीर्षलेख का पालन करते हैं) लेकिन अंतिम उपभोक्ता खपत के लिए शामिल किया जा सकता है। उपयोगकर्ता को रीलोड/रीफ्रेश बटन हिट करने पर Last-Modified हेडर सहित सर्वर डेटा स्थानांतरण भी कम हो सकता है। यदि Last-Modified हेडर जोड़ा गया है, तो इसे आविष्कार किए गए वास्तविक डेटा को प्रतिबिंबित करना चाहिए। यदि आप सर्वर डेटा ट्रांसफर को कम करना चाहते हैं (यदि उपयोगकर्ता रीलोड/रीफ्रेश बटन हिट करता है) और वास्तविक Last-Modified हेडर शामिल नहीं कर सकता है, तो आप सशर्त जीईटी (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26) को अनुमति देने के लिए ETag शीर्षलेख जोड़ सकते हैं। यदि आप पहले से ही Last-Modified भी शामिल कर रहे हैं तो ETag भी अपशिष्ट है। ध्यान दें कि Last-Modified स्पष्ट रूप से बेहतर है क्योंकि यह HTTP/1.0 क्लाइंट और प्रॉक्सी द्वारा भी समर्थित है। गतिशील पृष्ठों के मामले में ETag के लिए उपयुक्त मान पृष्ठ/संसाधन की सामग्री का SHA-1 है। ध्यान दें कि Last-Modified या ETag का उपयोग सर्वर लोड के साथ मदद नहीं करेगा, केवल सर्वर आउटगोइंग इंटरनेट पाइप/डेटा स्थानांतरण दर के साथ।

स्टेटिक गैर-सार्वजनिक सामग्री

Date: <current time> 
Expires: <current time> 
Cache-Control: private, max-age=31536000, s-maxage=0 
Vary: Cookie 

दलील: Date और Expires हेडर HTTP/1.0 संगतता के लिए कर रहे हैं और उस प्रतिक्रिया निजी है निर्दिष्ट करने के लिए कोई समझदार तरीका नहीं है, इन हेडर कि संवाद प्रतिक्रिया कैश नहीं किया जा सकता है। Cache-Control हेडर बताता है कि यह प्रतिक्रिया निजी कैश द्वारा कैश की जा सकती है लेकिन साझा कैश प्रतिक्रिया को कैश नहीं कर सकता है। s-maxage=0 जोड़ा गया है क्योंकि private को सभी प्रॉक्सी द्वारा समर्थित नहीं किया जा सकता है जो Cache-Control (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3 का समर्थन करता है - मुझे नहीं पता कि कौन से प्रॉक्सी टूटे हुए हैं)। max-age60*60*24*365 (1 वर्ष) के मान पर सेट है क्योंकि HTTP/1.1 विनिर्देश इस पैरामीटर के लिए किसी भी ऊपरी सीमा को परिभाषित नहीं करता है, मुझे लगता है कि यह कार्यान्वयन निर्भर है। Expires शीर्षकों को भविष्य में एक वर्ष तक सीमित होना चाहिए, इसलिए यहां एक ही तर्क का उपयोग करना ठीक होना चाहिए। Vary: Cookie शीर्षलेख आवश्यक है क्योंकि सत्र का उपयोग यह देखने के लिए किया जाता है कि विज़िटर को सामग्री देखने की अनुमति है या नहीं, कुकी में स्थानांतरित किया जाता है; क्योंकि लौटाई गई प्रतिक्रिया कुकी मान पर निर्भर करती है क्योंकि कुकी हेडर बदल जाता है तो कैश कैश्ड प्रतिक्रिया का उपयोग नहीं कर सकता है।

मैं व्यक्तिगत रूप से अंतिम भाग तोड़ सकता हूं। Vary: Cookie शीर्षलेख सहित नहीं, मैं बहुत सी कैशिंग में सुधार कर सकता हूं। उदाहरण के लिए: मेरे पास http://domain.com/icon/12 पर प्रोफ़ाइल छवि है जो केवल चयनित प्रमाणीकृत उपयोगकर्ताओं के लिए लौटा दी गई है। मेरे पास सत्र आईडी 5f2 के साथ एक आगंतुक X है और मैं उस उपयोगकर्ता को उस छवि को अनुमति देता हूं। आगंतुक X लॉग आउट करता है और फिर बाद में लॉग इन करता है। अब X में सत्र आईडी 2e8 है जो उसकी सत्र कुकी में संग्रहीत है। अगर मेरे पास Vary: cookie है, तो X का उपयोगकर्ता एजेंट कैश किए गए चित्र का उपयोग नहीं कर सकता है और इसे अपने कैश में पुनः लोड करने के लिए मजबूर किया जाता है। चूंकि सामग्री कुकी द्वारा भिन्न होती है, इसलिए अंतिम संशोधन समय के साथ एक सशर्त जीईटी का उपयोग नहीं किया जा सकता है।मैंने परीक्षण नहीं किया है यदि ETag का उपयोग इस मामले में मदद कर सकता है क्योंकि उस स्थिति में, सर्वर प्रतिक्रिया वही होगी (प्रतिक्रिया की सामग्री से गणना की गई SHA-1 ETag से मेल करें)। चेतावनी दीजिये कि इंटरनेट एक्सप्लोरर (कम से कम संस्करण 9 तक) हमेशा संसाधनों के लिए सशर्त जीईटी को मजबूर करता है जिसमें Vary: Cookie (स्रोत: http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx) शामिल हैं। ऐसा इसलिए है क्योंकि एमएसआईई के आंतरिक कैश कार्यान्वयन को याद नहीं है कि कुकी ने पहली बार किस बार भेजा था, इसलिए यह नहीं पता कि वर्तमान कुकी एक ही है या नहीं।

हालांकि, यह एक समस्या का एक उदाहरण है जो Vary: Cookie हेडर को छोड़कर यह दिखाने के लिए होता है कि यह वास्तव में तकनीकी रूप से सही व्यवहार के लिए क्यों आवश्यक है। उपर्युक्त उदाहरण देखें और कल्पना करें कि एक्स के लॉग आउट होने के बाद, विज़िटर वाई उसी उपयोगकर्ता एजेंट के साथ लॉग इन करता है (उपयोगकर्ता एजेंट एक्स और वाई के बीच पुनरारंभ हो सकता है, इससे कोई फर्क नहीं पड़ता)। यदि वाई कोई पृष्ठ देखता है जिसमें http://domain.com/icon/12 का लिंक शामिल है तो वाई पृष्ठ के अंदर एम्बेड किए गए आइकन को देखेगा, भले ही वाई आइकन को देखने में सक्षम न हो, यदि एक्स पहले उसी उपयोगकर्ता एजेंट का उपयोग नहीं कर रहा था। मेरे मामले में मैं इसे एक बड़ी पर्याप्त समस्या पर विचार नहीं करता क्योंकि वाई संभवतः Vary: Cookie के बावजूद उपयोगकर्ता एजेंट कैश का निरीक्षण करके मैन्युअल रूप से आइकन तक पहुंचने में सक्षम होगा। हालांकि, यह समस्या वाई को यह ध्यान देने से रोक सकती है कि वह तकनीकी रूप से इस सामग्री तक पहुंच नहीं पाएगा (यह महत्वपूर्ण हो सकता है जैसे कि वाई सामग्री को सह-लेखन कर रहा हो)। यदि सामग्री को संवेदनशील माना जाता है, तो सर्वर को को Cache-Control निर्देश के कारण होने वाली समस्याओं के बावजूद no-store भेजना होगा।

यहां भी Last-Modified हेडर जोड़ने से उपयोगकर्ताओं को रीलोड/रीफ्रेश बटन मारने में मदद मिलेगी (ऊपर चर्चा देखें)।

वाष्पशील सार्वजनिक सामग्री

Date: <current time> 
Expires: <current time> 
Cache-Control: public, max-age=0, s-maxage=0 
Last-Modified: <real-last-modification-time> 

दलील: बताओ HTTP/1.0 ग्राहकों और प्रॉक्सी का यह प्रतिक्रिया तुरंत बासी विचार किया जाना चाहिए। Last-Modified समय को संसाधनों के डेटा ट्रांसमिशन को छोड़ने के लिए समय शामिल किया गया है जब संसाधन को फिर से एक्सेस किया जाता है और क्लाइंट सशर्त जीईटी का समर्थन करता है। यदि Last-Modified का उपयोग नहीं किया जा सकता है, ETag प्रतिस्थापन के रूप में उपयोग किया जा सकता है (ऊपर चर्चा देखें)। HTTP/1.0 संगत ग्राहकों के साथ सशर्त जीईटी की अनुमति देने के लिए Last-Modified का उपयोग करना महत्वपूर्ण है।

यदि सामग्री को थोड़ा सा देरी हो सकती है, तो Expires, max-age और s-maxage [sic] उपयुक्त रूप से समायोजित किया जाना चाहिए। उदाहरण के लिए, उन लोगों को 5 सेकंड जोड़ने से अत्यधिक लोकप्रिय साइट के लिए बहुत मदद मिल सकती है, जैसा सिम्बियन के उत्तर द्वारा सुझाया गया है। ध्यान दें कि सशर्त जीईटी के विपरीत, समाप्ति समय में वृद्धि सर्वर आउटगोइंग डेटा यातायात को कम करने के बजाय सर्वर लोड को कम कर देगी (क्योंकि सर्वर कुल में कम अनुरोध देखेंगे)।

वाष्पशील गैर-सार्वजनिक सामग्री

Date: <current time> 
Expires: <current time> 
Cache-Control: private, max-age=0, s-maxage=0 
Last-Modified: <real-last-modification-time> 
Vary: Cookie 

दलील: बताओ HTTP/1.0 ग्राहकों और प्रॉक्सी का यह प्रतिक्रिया तुरंत बासी विचार किया जाना चाहिए। Last-Modified समय को संसाधनों के डेटा ट्रांसमिशन को छोड़ने के लिए समय शामिल किया गया है जब संसाधन को फिर से एक्सेस किया जाता है और क्लाइंट सशर्त जीईटी का समर्थन करता है। यदि Last-Modified का उपयोग नहीं किया जा सकता है, ETag प्रतिस्थापन के रूप में उपयोग किया जा सकता है (ऊपर चर्चा देखें)। HTTP/1.0 संगत ग्राहकों के साथ सशर्त जीईटी की अनुमति देने के लिए Last-Modified का उपयोग करना महत्वपूर्ण है। यह भी ध्यान रखें कि Cache-Control में no-cache, must-revalidate या no-store शामिल नहीं होना चाहिए क्योंकि इनमें से किसी भी निर्देश का उपयोग कम से कम एक उपयोगकर्ता एजेंट में बैक बटन को तोड़ देगा।हालांकि, यदि सर्वर स्थानांतरित करने वाली सामग्री में संवेदनशील सामग्री होती है जिसे स्थायी संग्रहण में संग्रहीत नहीं किया जाना चाहिए, तो no-store ध्वज बैक बटन को तोड़ने के बावजूद उपयोग किया जाना चाहिए। चेतावनी: ध्यान दें कि no-store का उपयोग हार्ड डिस्क पर एन्क्रिप्शन के बिना हार्ड डिस्क पर समाप्त होने वाली संवेदनशील सामग्री को रोक नहीं सकता है यदि ऑपरेटिंग सिस्टम स्वैपिंग सक्षम है और स्वैप एन्क्रिप्ट नहीं किया गया है! यह भी ध्यान रखें कि no-store का उपयोग बहुत कम समझ में आता है जब तक कि कनेक्शन एन्क्रिप्ट नहीं किया जाता है (HTTPS/SSL)।

Answer 2

ज्यादातर ठीक है, लेकिन आप ध्यान रखें कि HTTP/1.0 प्रॉक्सी सामग्री को कैश कर सकते हैं

Cache-Control: private 

के रूप में परोसा तो तुम साथ ही एक स्पष्ट तिथि संशोधित हेडर स्थापित करना चाहिए के रूप में समाप्त हो रहा है में रखना करने की आवश्यकता है हैडर।

अपनी 'स्टेटिक गैर-सार्वजनिक सामग्री' के लिए आपको 'भिन्न: कुकी' शीर्षलेख जोड़ना चाहिए।

आपकी 'अस्थिर सार्वजनिक सामग्री' के लिए: यह कितनी तेज़ी से बदल रहा है? +5 सेकंड का टीटीएल सेट करना आपके सर्वर से बहुत सारे प्रयासों को ऑफ़लोड कर सकता है।

'अस्थिर गैर-सार्वजनिक सामग्री' के लिए आपको शायद कैश-कंट्रोल हेडर में नो-कैश जोड़ना चाहिए।

सर्वर से जारी प्रगामा शीर्षकों का क्लाइंट और न ही प्रॉक्सी पर कोई प्रभाव नहीं होना चाहिए।

क्या परीक्षण क्या होता है जब अपने कैश समाप्त हो रहा है (IME आप/304 प्रतिक्रियाएं एक प्रणाली एक सब सशर्त अनुरोध की वजह से कोई आबादी वाले कैश के साथ पहुँचा से भी धीमी साथ खत्म कर सकते हैं)