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

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

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

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

हेडर	सहायता
Cache-Control	यह बैकएंड ऑरिजिन सर्वर से मिले रिस्पॉन्स के लिए काम करता है, लेकिन क्लाइंट के अनुरोधों के लिए नहीं. Edge, निर्देशों के सबसेट के साथ काम करता है.
समयसीमा खत्म होने की तारीख	काम करता है. इसे बदला जा सकता है.
इकाई टैग (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 कॉल का इस्तेमाल करके बनाए गए टारगेट एंडपॉइंट, दोनों शामिल हो सकते हैं.

कैश-कंट्रोल की सहायता से जुड़ी सीमाएं

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 स्पेसिफ़िकेशन के सबसेट डायरेक्टिव के साथ काम करता है. नीचे दी गई टेबल में, एचटीटीपी कैश-कंट्रोल रिस्पॉन्स हेडर के लिए, Apigee Edge के साथ काम करने वाले डायरेक्टिव के बारे में बताया गया है.

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

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

ख़त्म होने की तारीख़

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

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

खत्म होने की तारीख: गुरुवार, 01 दिसंबर, 1994 16:00:00 GMT

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

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

ETag

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

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

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

If-Match

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

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

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

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

If-None-Match

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

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

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

If-Modified-Since

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

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

Accept-Encoding

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

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