मैंने Google में कुछ पृष्ठ हिट किए हैं जहाँ आप व्यक्तिगत वस्तुओं के लिए S3 में हैडर सेट कर सकते हैं। यह वास्तव में विशेष रूप से ऐसा करने का एक उत्पादक तरीका नहीं है क्योंकि मेरे मामले में हम कई वस्तुओं की बात कर रहे हैं।
ठीक है, "उत्पादक" या नहीं, यह वास्तव में काम करने के लिए डिज़ाइन किया गया है।
CloudFront हेडर नहीं जोड़ता है Cache-Control: ।
CloudFront गुजरता के माध्यम से (और भी सम्मान करता, जब तक अन्यथा कॉन्फ़िगर है)Cache-Control: मूल सर्वर, जो इस मामले में S3 है द्वारा प्रदान की हेडर।
Cache-Control:किसी ऑब्जेक्ट के प्राप्त होने पर S3 द्वारा हेडर प्रदान करने के लिए , उन्हें तब प्रदान किया जाना चाहिए जब ऑब्जेक्ट को S3 में अपलोड किया जाता है, या बाद के पुट + कॉपी ऑपरेशन द्वारा ऑब्जेक्ट के मेटाडेटा में जोड़ा जाता है, जिसका उपयोग आंतरिक रूप से किसी ऑब्जेक्ट को स्वयं कॉपी करने के लिए किया जा सकता है S3, प्रक्रिया में मेटाडेटा को संशोधित करता है। यदि आप ऑब्जेक्ट मेटाडेटा को संपादित करते हैं, तो यह पर्दे के पीछे से कंसोल करता है।
वहाँ भी है (अगर आप सोच रहे हैं) S3 में कोई वैश्विक सेटिंग नहीं है कि इन हेडर को वापस करने के लिए एक बाल्टी में सभी ऑब्जेक्ट्स को मजबूर करने के लिए - यह एक प्रति-वस्तु विशेषता है।
अपडेट: लैम्ब्डा @ एज क्लाउडफ्रंट में एक नई विशेषता है जो आपको दर्शक और कैश और / या कैश और मूल के बीच अनुरोधों और / या प्रतिक्रियाओं के खिलाफ ट्रिगर करने की अनुमति देता है, एक सरल अनुरोध / प्रतिक्रिया ऑब्जेक्ट संरचना के खिलाफ Node.js में लिखा कोड चल रहा है। CloudFront द्वारा उजागर।
इस सुविधा के लिए मुख्य अनुप्रयोगों में से एक हेडर से छेड़छाड़ कर रहा है ... इसलिए जबकि ऊपर अभी भी सटीक है - CloudFront खुद को नहीं जोड़ता है Cache-Control- अब यह एक Lambda फ़ंक्शन के लिए संभव है कि वह CloudFront से लौटी प्रतिक्रिया पर उन्हें जोड़ दे।
यह उदाहरण Cache-Control: public, max-age=86400केवल तभी जोड़ता है Cache-Controlजब प्रतिक्रिया पर कोई हेडर पहले से मौजूद न हो ।
एक ओरिजनल रिस्पॉन्स ट्रिगर में इस कोड का उपयोग करने से हर बार क्लाउडफ्रंट मूल से एक ऑब्जेक्ट प्राप्त करने के लिए आग का कारण बनता है, और CloudFront इसे कैश करने से पहले प्रतिक्रिया को संशोधित करता है।
'use strict';
exports.handler = (event, context, callback) => {
const response = event.Records[0].cf.response;
if(!response.headers['cache-control'])
{
response.headers['cache-control'] = [{
key: 'Cache-Control',
value: 'public, max-age=86400'
}];
}
callback(null, response);
};
अद्यतन (2018/06/20): हाल ही में, मैं CloudFront टीम के लिए एक सुविधा का अनुरोध प्रस्तुत स्थिर मूल के विन्यास अनुमति देने के लिए प्रतिक्रिया मूल गुण, जिस तरह से स्थिर करने के लिए इसी तरह के रूप में हेडर अनुरोध हेडर, जोड़ा जा सकता है अब ... लेकिन एक साथ मोड़, प्रत्येक हेडर को सशर्त रूप से जोड़ने की अनुमति देता है (केवल अगर मूल प्रतिक्रिया में उस हेडर को प्रदान नहीं करता है) या बिना शर्त (हेडर को जोड़ने और हेडर को फिर से लिखना शुरू करता है, यदि वर्तमान में)।
फ़ीचर अनुरोधों के साथ, आपको आमतौर पर इस बात की कोई पुष्टि नहीं मिलती है कि क्या वे वास्तव में नई सुविधा को लागू करने पर विचार कर रहे हैं ... या फिर चाहे वे पहले से ही इस पर काम कर रहे हों ... यह अभी घोषणा की गई है जब वे कर रहे हैं। इसलिए, मुझे नहीं पता कि ये लागू किए जाएंगे या नहीं। ऐसा तर्क दिया जाना चाहिए कि चूंकि यह क्षमता पहले से ही लैम्ब्डा @ एज के माध्यम से उपलब्ध है, इसलिए आधार कार्यक्षमता में इसकी कोई आवश्यकता नहीं है ... लेकिन मेरा प्रतिवाद यह है कि आधार कार्यात्मक रूप से क्षमता के बिना फीचर-पूर्ण नहीं है। सरल, स्थैतिक प्रतिक्रिया हेडर हेरफेर करें, और यदि यह एकमात्र कारण है कि ट्रिगर की आवश्यकता है, तो लैम्बडा ट्रिगर्स की आवश्यकता एक अनावश्यक लागत है, आर्थिक रूप से और अतिरिक्त विलंबता में (भले ही जरूरी नहीं कि एक बाहरी लागत हो)।