एचटीटीपी रिस्पॉन्स हेडर के लिए सहायता

यह Apigee Edge के दस्तावेज़ हैं.
पर जाएं Apigee X दस्तावेज़. info

इस विषय में बताया गया है कि ResponseCache नीति का इस्तेमाल करने पर, Edge, एचटीटीपी/1.1 कैश मेमोरी में सेव करने वाले हेडर को कैसे मैनेज करता है. Apigee Edge, फ़िलहाल एचटीटीपी/1.1 कैश मेमोरी में सेव करने वाले हेडर और डायरेक्टिव के सबसेट के साथ काम करता है. इस विषय में, उन सुविधाओं के बारे में बताया गया है जो काम नहीं करती हैं. ये हेडर और डायरेक्टिव, बैकएंड टारगेट (ऑरिजिन) सर्वर से मिलते हैं.

इसके अलावा, कुछ हेडर के लिए, Edge उनके डायरेक्टिव के आधार पर कार्रवाई करता है. कुछ मामलों में, ये एचटीटीपी/1.1 कैश हेडर, ResponseCache नीति में बताए गए किसी भी तरीके को बदल देते हैं. उदाहरण के लिए, अगर बैकएंड सर्वर से Cache-Control हेडर मिलता है, तो आपके पास हेडर के s-maxage डायरेक्टिव को नीति में मौजूद समयसीमा खत्म होने की अन्य सेटिंग पर लागू करने का विकल्प होता है.

हेडर	सहायता
Cache-Control	बैकएंड ऑरिजिन सर्वर से मिलने वाले रिस्पॉन्स के लिए, यह हेडर काम करता है. हालांकि, क्लाइंट के अनुरोधों के लिए यह काम नहीं करता. Edge, डायरेक्टिव के सबसेट के साथ काम करता है.
Expires	यह हेडर काम करता है. इसे बदला जा सकता है.
Entity Tags (ETags)	If-Match और If-None-Match के लिए खास तरीका.
If-Modified-Since	GET अनुरोधों पर, हेडर को मूल सर्वर पर भेजा जाता है. भले ही, कैश मेमोरी में मान्य एंट्री मौजूद हो.
Accept-Encoding	Edge, आने वाले हेडर के आधार पर, कंप्रेस किए गए या कंप्रेस न किए गए रिस्पॉन्स भेजता है.

Cache-Control

Apigee Edge, Cache-Control हेडर का इस्तेमाल सिर्फ़ बैकएंड ऑरिजिन सर्वर से मिलने वाले रिस्पॉन्स के लिए करता है. एचटीटीपी/1.1 की खास जानकारी के मुताबिक, Cache-Control हेडर का इस्तेमाल क्लाइंट के अनुरोधों और ऑरिजिन सर्वर के रिस्पॉन्स, दोनों के लिए किया जा सकता है. ऑरिजिन सर्वर में, Apigee Edge API प्रॉक्सी में तय किए गए टारगेट एंडपॉइंट और TargetServer API कॉल का इस्तेमाल करके बनाए गए एंडपॉइंट, दोनों शामिल हो सकते हैं.

Cache-Control के साथ काम करने की सीमाओं के बारे में जानकारी

Apigee Edge, एचटीटीपी/1.1 की खास जानकारी में तय किए गए Cache-Control रिस्पॉन्स हेडर की सुविधाओं के सबसेट के साथ काम करता है. कृपया इन बातों का ध्यान रखें:

• Apigee Edge, क्लाइंट के इनबाउंड अनुरोधों के साथ आने वाले Cache-Control हेडर के साथ काम नहीं करता.
• Apigee Edge, सिर्फ़ सार्वजनिक कैश मेमोरी के साथ काम करता है. (एचटीटीपी की खास जानकारी के मुताबिक, Cache-Control को सार्वजनिक (शेयर की गई) या निजी (एकल उपयोगकर्ता) के तौर पर सेट किया जा सकता है.)
• Apigee Edge, एचटीटीपी/1.1 की खास जानकारी में मौजूद Cache-Control रिस्पॉन्स डायरेक्टिव के सबसेट के साथ ही काम करता है. ज़्यादा जानकारी के लिए, Cache-Control रिस्पॉन्स हेडर डायरेक्टिव के साथ काम करने की सुविधा देखें.

Cache-Control रिस्पॉन्स हेडर डायरेक्टिव के साथ काम करने की सुविधा

Apigee, ऑरिजिन सर्वर से मिलने वाले रिस्पॉन्स के लिए, एचटीटीपी/1.1 की खास जानकारी में मौजूद डायरेक्टिव के सबसेट के साथ काम करता है. यहां दी गई टेबल में, एचटीटीपी Cache-Control रिस्पॉन्स हेडर डायरेक्टिव के लिए, Apigee Edge के साथ काम करने की सुविधा के बारे में बताया गया है.

यहां दिए गए डायरेक्टिव के बारे में ज़्यादा जानकारी के लिए, एचटीटीपी/1.1 की खास जानकारी में Cache-Control देखें.

Cache-Control डायरेक्टिव	Apigee Edge, डायरेक्टिव को कैसे प्रोसेस करता है
cache-extension	यह डायरेक्टिव काम नहीं करता.
max-age	अगर आपकी ResponseCache नीति में <UseResponseCacheHeaders> एलिमेंट को true पर सेट किया गया है, तो इस डायरेक्टिव में तय की गई सेकंड की संख्या के लिए, रिस्पॉन्स को कैश मेमोरी में सेव किया जा सकता है. यह डायरेक्टिव, s-maxage डायरेक्टिव से बदल जाता है. साथ ही, यह Expires हेडर को भी बदल देता है. इसे नीति के <ExpirySettings> एलिमेंट से भी बदला जा सकता है. ज़्यादा जानकारी के लिए, ResponseCache नीति में "कैश एंट्री की समयसीमा खत्म होने की तारीख सेट करना" और <UseResponseCacheHeaders> देखें.
must-revalidate	यह डायरेक्टिव काम नहीं करता. Apigee Edge, कैश मेमोरी में सेव की गई सभी एंट्री की समयसीमा खत्म होने के तुरंत बाद उन्हें मिटा देता है.
no-cache	Edge, ऑरिजिन के रिस्पॉन्स को कैश मेमोरी में सेव करता है. हालांकि, क्लाइंट के किसी भी अगले अनुरोध को पूरा करने के लिए, इसका इस्तेमाल करने से पहले, मूल सर्वर से इसकी पुष्टि करनी होगी. इस नियम के तहत, ऑरिजिन 304 Not Modified रिस्पॉन्स दिखा सकता है. इससे यह पता चलता है कि रिस्पॉन्स को कैश मेमोरी से वापस पाना चाहिए. इससे, पूरे रिस्पॉन्स को वापस पाने के लिए ज़रूरी प्रोसेसिंग बच जाती है. अगर ऑरिजिन सर्वर, पूरा रिस्पॉन्स दिखाता है, तो यह कैश मेमोरी में मौजूद एंट्री की जगह ले लेता है. इस डायरेक्टिव के साथ तय किए गए किसी भी फ़ील्ड के नाम को अनदेखा कर दिया जाता है.
no-store	यह डायरेक्टिव काम नहीं करता.
no-transform	यह डायरेक्टिव काम नहीं करता.
private	यह डायरेक्टिव काम नहीं करता. अगर यह डायरेक्टिव मिलता है, तो ऑरिजिन के रिस्पॉन्स को कैश मेमोरी में सेव नहीं किया जाता. किसी भी फ़ील्ड के नाम को अनदेखा कर दिया जाता है.
proxy-revalidate	यह डायरेक्टिव काम नहीं करता. Apigee Edge, कैश मेमोरी में सेव की गई सभी एंट्री की समयसीमा खत्म होने के तुरंत बाद उन्हें मिटा देता है.
public	Edge, ऑरिजिन के रिस्पॉन्स को कैश मेमोरी में सेव करता है. भले ही, अन्य डायरेक्टिव इसके उलट कुछ और बताते हों. एचटीटीपी/1.1 की खास जानकारी के मुताबिक, इस नियम का सिर्फ़ एक अपवाद है. वह यह है कि अगर रिस्पॉन्स में Authorization हेडर शामिल है.
s-maxage	अगर आपकी ResponseCache नीति में <UseResponseCacheHeaders> एलिमेंट को true पर सेट किया गया है, तो इस डायरेक्टिव में तय की गई सेकंड की संख्या के लिए, रिस्पॉन्स को कैश मेमोरी में सेव किया जा सकता है. यह डायरेक्टिव, max-age डायरेक्टिव और Expires हेडर को बदल देता है. इसे नीति के <ExpirySettings> एलिमेंट से बदला जा सकता है. ज़्यादा जानकारी के लिए, ResponseCache नीति में "कैश एंट्री की समयसीमा खत्म होने की तारीख सेट करना" और <UseResponseCacheHeaders> देखें.

Expires

जब ResponseCache नीति में UseResponseCacheHeaders फ़्लैग को true पर सेट किया जाता है, तो Edge, कैश मेमोरी में सेव की गई एंट्री का टाइम टू लिव (टीटीएल) तय करने के लिए, Expires हेडर का इस्तेमाल कर सकता है. इस हेडर में, ऐसी तारीख/समय तय किया जाता है जिसके बाद, रिस्पॉन्स की कैश मेमोरी में सेव की गई एंट्री को पुरानी माना जाता है. इस हेडर की मदद से, सर्वर यह बता सकते हैं कि टाइमस्टैंप के आधार पर, कैश मेमोरी में सेव की गई वैल्यू को कब वापस पाया जा सकता है.

Expires हेडर के लिए, तारीख के मान्य फ़ॉर्मैट के बारे में एचटीटीपी/1.1 की खास जानकारी में बताया गया है. उदाहरण के लिए:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

एचटीटीपी तारीख/समय के फ़ॉर्मैट के बारे में ज़्यादा जानकारी के लिए, एचटीटीपी/1.1 की खास जानकारी में तारीख/समय के फ़ॉर्मैट देखें.

Expires हेडर के बारे में ज़्यादा जानकारी के लिए, हेडर फ़ील्ड की परिभाषाएं एचटीटीपी/1.1 की खास जानकारी में देखें.

ETag

Entity Tag (ETag) एक ऐसा आइडेंटिफ़ायर है जो अनुरोध किए गए संसाधन से जुड़ा होता है. ETag का इस्तेमाल करके, एक सर्वर यह तय कर सकता है कि अनुरोध किया गया संसाधन और कैश मेमोरी में सेव किया गया उससे जुड़ा संसाधन, दोनों एक ही हैं या नहीं. उदाहरण के लिए, अगर सर्वर को लगता है कि अनुरोध किया गया संसाधन और कैश मेमोरी में सेव किया गया उससे जुड़ा संसाधन, दोनों एक ही नहीं हैं, तो वह रिस्पॉन्स को फिर से कैश मेमोरी में सेव कर सकता है. अगर ETags एक ही हैं, तो वह कैश मेमोरी में सेव किए गए संसाधन को वापस पा सकता है.

जब टारगेट एंडपॉइंट, ETag के साथ Edge को रिस्पॉन्स भेजता है, तो Edge, ETag को रिस्पॉन्स के साथ कैश मेमोरी में सेव कर लेता है.

Entity Tags के बारे में ज़्यादा जानने के लिए, प्रोटोकॉल पैरामीटर एचटीटीपी/1.1 की खास जानकारी में देखें.

If-Match

If-Match अनुरोध का हेडर के साथ, कैश मेमोरी में सेव की गई एंटिटी, मौजूदा एंटिटी होती है. ऐसा तब होता है, जब हेडर में मौजूद ETag, कैश मेमोरी में सेव किए गए ETag से मेल खाता है. GET के अलावा, ऐसे सभी अनुरोध जिनमें If-Match हेडर तय किया गया है, उन्हें मूल सर्वर पर भेजा जाता है. इससे यह पक्का किया जाता है कि मूल की कैश मेमोरी में सेव करने की सुविधाओं को अनुरोध प्रोसेस करने का मौका मिले.

If-Match के बारे में ज़्यादा जानने के लिए, एचटीटीपी/1.1 की खास जानकारी में हेडर फ़ील्ड की परिभाषाएं देखें.

अगर Edge को क्लाइंट से इनबाउंड GET अनुरोध मिलता है, जिसमें एक If-Match हेडर शामिल है, तो:

अगर	इसके बाद
If-Match हेडर में एक या उससे ज़्यादा ETags तय किए गए हैं	Apigee Edge, तय किए गए संसाधन के लिए, समयसीमा खत्म न हुई कैश मेमोरी में सेव की गई सभी एंट्री वापस पाता है. साथ ही, कैश मेमोरी में सेव की गई उन एंट्री पर मौजूद सभी मज़बूत ETags की तुलना, If-Match हेडर में तय किए गए ETags से करता है. अगर कोई मैच मिलता है, तो कैश मेमोरी में सेव की गई एंट्री वापस पाई जाती है. अगर कोई मैच नहीं मिलता है, तो अनुरोध को मूल सर्वर पर भेजा जाता है.
If-Match हेडर में "*" तय किया गया है	अनुरोध को मूल सर्वर पर भेजा जाता है. इससे यह पक्का किया जाता है कि ऑरिजिन की कैश मेमोरी में सेव करने की सुविधाओं को अनुरोध प्रोसेस करने का मौका मिले
अनुरोध के एक ही यूआरआई वाली कैश मेमोरी में सेव की गई एंट्री मिलती है, लेकिन इसमें सिर्फ़ कमज़ोर ETags होते हैं	क्लाइंट को एंट्री वापस भेजने से पहले, मूल सर्वर से इसकी पुष्टि करनी होगी
ETags, मूल सर्वर से मिलते हैं.	ETag को क्लाइंट को बिना किसी बदलाव के वापस भेजा जाता है

If-None-Match

If-None-Match हेडर के साथ, कैश मेमोरी में सेव की गई एंटिटी, मौजूदा एंटिटी होती है. ऐसा तब होता है, जब हेडर में मौजूद ETag, कैश मेमोरी में सेव किए गए ETag से मेल नहीं खाता है. GET के अलावा, ऐसे सभी अनुरोध जिनमें यह हेडर शामिल है, उन्हें मूल सर्वर पर भेजा जाता है.

अगर Edge को इस हेडर के साथ इनबाउंड GET अनुरोध मिलता है, तो:

अगर	इसके बाद
If-None-Match हेडर में एक या उससे ज़्यादा ETags तय किए गए हैं	Apigee Edge, तय किए गए यूआरआई के लिए, समयसीमा खत्म न हुई कैश मेमोरी में सेव की गई सभी एंट्री वापस पाता है. साथ ही, कैश मेमोरी में सेव की गई उन एंट्री पर मौजूद सभी मज़बूत ETags की तुलना, तय किए गए If-None-Match हेडर से करता है. अगर कोई मैच मिलता है, तो Edge, 304 Not Modified स्टेटस दिखाता है. अगर कोई मैच नहीं मिलता है, Edge, अनुरोध को मूल सर्वर पर भेजता है.
If-None-Match हेडर में "*" तय किया गया है और अनुरोध किए गए यूआरआई के लिए, समयसीमा खत्म न हुई कैश मेमोरी में सेव की गई एंट्री मौजूद है	Edge, 304 Not Modified स्टेटस दिखाता है
अनुरोध के एक ही यूआरआई वाली कैश मेमोरी में सेव की गई एंट्री मिलती है, लेकिन इसमें सिर्फ़ कमज़ोर ETags होते हैं	क्लाइंट को एंट्री वापस भेजने से पहले, Edge को मूल सर्वर से इसकी पुष्टि करनी होगी
Edge को मूल सर्वर से ETag मिलता है	ETag को क्लाइंट को बिना किसी बदलाव के वापस भेजा जाता है

If-Modified-Since

अगर Apigee Edge को जीईटी अनुरोध में If-Modified-Since हेडर मिलता है, तो इसे मूल सर्वर पर भेजा जाता है. भले ही, कैश मेमोरी में मान्य एंट्री मौजूद हो.

इससे यह पक्का किया जाता है कि किसी संसाधन में किए गए ऐसे सभी अपडेट को ध्यान में रखा जाए जो Apigee Edge के ज़रिए नहीं किए गए हैं अगर ऑरिजिन सर्वर, नई एंटिटी दिखाता है, तो Edge, कैश मेमोरी में मौजूद एंट्री को नई वैल्यू से बदल देता है. अगर सर्वर, 304 Not Modified स्टेटस दिखाता है, तो Edge, रिस्पॉन्स की वैल्यू दिखाता है. ऐसा तब होता है, जब कैश मेमोरी में सेव किए गए रिस्पॉन्स के Last-Modified हेडर से पता चलता है कि इसमें कोई बदलाव नहीं हुआ है.

Accept-Encoding

जब आने वाले अनुरोध में, Accept-Encoding हेडर शामिल होता है, जिसकी वैल्यू gzip, deflate या compress होती है, तो मूल सर्वर, कंप्रेस किया गया डेटा दिखाता है. जब अगले अनुरोध, Accept-Encoding हेडर के बिना आते हैं, तो उन्हें कंप्रेस न किया गया रिस्पॉन्स मिलने की उम्मीद होती है. Apigee का रिस्पॉन्स कैश मेमोरी में सेव करने का तरीका, मूल सर्वर पर वापस जाए बिना, आने वाले हेडर के आधार पर, कंप्रेस किए गए और कंप्रेस न किए गए, दोनों तरह के रिस्पॉन्स भेज सकता है.

कैश कुंजियों में Accept हेडर की वैल्यू जोड़ी जा सकती हैं. इससे, हर कैश मेमोरी में सेव किए गए आइटम के लिए, कुंजियां ज़्यादा काम की बन जाती हैं. ज़्यादा जानकारी के लिए, ResponseCache नीति में "कैश कुंजी कॉन्फ़िगर करना" देखें.