बहुत सरल कैशिंग शब्दार्थ के साथ: यदि पैरामीटर समान हैं (और URL समान है, तो निश्चित रूप से), तो यह एक हिट है। क्या यह संभव है? सिफारिश की?
बहुत सरल कैशिंग शब्दार्थ के साथ: यदि पैरामीटर समान हैं (और URL समान है, तो निश्चित रूप से), तो यह एक हिट है। क्या यह संभव है? सिफारिश की?
जवाबों:
धारा 9.5 (POST) में संगत RFC 2616 , POST संदेश के जवाब की कैशिंग की अनुमति देता है , यदि आप उपयुक्त उत्पादकों का उपयोग करते हैं।
जब तक प्रतिक्रिया में उपयुक्त कैशे-नियंत्रण या शीर्ष लेख फ़ील्ड शामिल नहीं होती हैं, तब तक इस विधि के लिए प्रतिक्रिया करने योग्य नहीं हैं। हालाँकि, 303 (अन्य देखें) प्रतिक्रिया का उपयोग उपयोगकर्ता एजेंट को निर्देश देने के लिए किया जा सकता है ताकि वह कैशेबल संसाधन प्राप्त कर सके।
ध्यान दें कि समान RFC धारा 13 (HTTP में कैशिंग) में स्पष्ट रूप से बताता है कि कैश को POST अनुरोध के बाद संबंधित इकाई को अमान्य करना चाहिए ।
कुछ HTTP तरीके एक इकाई को अमान्य करने के लिए कैश का कारण होना चाहिए। यह या तो अनुरोध-यूआरआई, या स्थान या सामग्री-स्थान हेडर (यदि मौजूद है) द्वारा संदर्भित इकाई है। ये तरीके हैं:
- PUT - DELETE - POST
यह मेरे लिए स्पष्ट नहीं है कि ये विनिर्देश कैसे सार्थक कैशिंग की अनुमति दे सकते हैं।
यह आरएफसी 7231 (धारा 4.3.3) में भी परिलक्षित और आगे स्पष्ट है , जो आरएफसी 2616 का पालन करता है।
POST अनुरोधों के लिए
जवाबदेही तभी संभव होती है जब उनमें स्पष्ट ताजगी की जानकारी शामिल हो (देखें [RFC7234] की धारा 4.2.1)।
हालांकि, POST कैशिंग व्यापक रूप से लागू नहीं किया गया है। उन मामलों के लिए जहां एक मूल सर्वर ग्राहक को एक POST के परिणाम को इस तरह से कैश करने में सक्षम होना चाहता है, जिसे बाद में GET द्वारा पुन: उपयोग किया जा सकता है, मूल सर्वर MAY परिणाम (सामग्री) के स्थान पर 200 (ओके) प्रतिक्रिया भेजता है हेडर फ़ील्ड जिसमें POST के प्रभावी अनुरोध URI (धारा 3.1.4.2) के समान मूल्य है।
इसके अनुसार, एक कैश किए गए POST (यदि यह क्षमता सर्वर द्वारा इंगित की गई है) का परिणाम बाद में उसी URI के लिए GET अनुरोध के परिणाम के रूप में उपयोग किया जा सकता है।
RFC 2616 धारा 9.5 के अनुसार:
"POST विधि के लिए जवाबदेही अस्वीकार्य नहीं हैं, प्रतिक्रिया को कम से कम कैश-कंट्रोल या एक्सपायर हेडर फ़ील्ड में शामिल करता है।"
तो, हाँ, आप POST अनुरोध प्रतिक्रिया को कैश कर सकते हैं लेकिन केवल अगर यह उचित हेडर के साथ आता है। ज्यादातर मामलों में आप प्रतिक्रिया को कैश नहीं करना चाहते हैं। लेकिन कुछ मामलों में - जैसे कि आप सर्वर पर कोई डेटा नहीं बचा रहे हैं - यह पूरी तरह से उचित है।
नोट, हालांकि वर्तमान फ़ायरफ़ॉक्स 3.0.10 सहित कई ब्राउज़र, हेडर की परवाह किए बिना POST प्रतिक्रिया को कैश नहीं करेंगे। IE इस संबंध में अधिक चालाकी से व्यवहार करता है।
अब, मैं RFC 2616 S. 13.10 के बारे में कुछ भ्रम को दूर करना चाहता हूं। URI पर POST विधि "कैशिंग के लिए संसाधन को अमान्य नहीं करता" जैसा कि कुछ ने यहां बताया है। यह उस URI बासी का पहले से कैश्ड संस्करण बनाता है, भले ही इसका कैश कंट्रोल हेडर लंबी अवधि की ताजगी का संकेत देता हो।
GETऔर POSTअनुरोधों के लिए उसी URI का उपयोग करते हैं। यदि आप क्लाइंट और सर्वर के बीच बैठे कैश हैं, तो आप देखते हैं GET /fooऔर आप प्रतिक्रिया को कैश करते हैं। आगे आप देखते POST /fooहैं कि आपको कैश की गई प्रतिक्रिया को अमान्य करने की आवश्यकता है, GET /fooभले ही POSTप्रतिक्रिया में कोई कैश कंट्रोल हेडर शामिल न हो क्योंकि वे एक ही यूआरआई हैं , इस प्रकार अगले GET /fooको फिर से अमान्य करना होगा भले ही मूल हेडर ने संकेत दिया हो कैश अभी भी होगा लाइव (यदि आपने POST /fooअनुरोध नहीं देखा था )
But in some cases - such as if you are not saving any data on the server - it's entirely appropriate.। पहले ऐसे POST API का क्या मतलब है?
कुल मिलाकर:
मूल रूप से POST एक बेकार ऑपरेशन नहीं है । इसलिए आप इसे कैशिंग के लिए उपयोग नहीं कर सकते। जीईटी एक आदर्श ऑपरेशन होना चाहिए, इसलिए इसे आमतौर पर कैशिंग के लिए उपयोग किया जाता है।
कृपया HTTP 1.1 RFC 2616 S. 9.1 का खंड 9.1 देखें ।
GET विधि के शब्दार्थ से इतर:
स्वयं POST विधि किसी संसाधन के लिए कुछ पोस्ट करने के लिए शब्दार्थ है। POST को कैश नहीं किया जा सकता है क्योंकि यदि आप दो बार बनाम तीन बार एक बार कुछ करते हैं, तो आप हर बार सर्वर के संसाधन को बदल रहे हैं। प्रत्येक अनुरोध मायने रखता है और इसे सर्वर तक पहुंचाया जाना चाहिए।
PUT पद्धति स्वयं एक संसाधन डालने या बनाने के लिए शब्दार्थ है। यह एक इम्पोटेंट ऑपरेशन है, लेकिन इसका उपयोग कैशिंग के लिए नहीं किया जाएगा क्योंकि इस दौरान एक DELETE हो सकता है।
DELETE विधि स्वयं एक संसाधन को हटाने के लिए शब्दार्थ है। यह एक आदर्श ऑपरेशन है, लेकिन इसका उपयोग कैशिंग के लिए नहीं किया जाएगा क्योंकि इस बीच एक PUT हो सकता है।
ग्राहक पक्ष कैशिंग के बारे में:
एक वेब ब्राउज़र हमेशा आपके अनुरोध को आगे बढ़ाएगा भले ही उसके पास पिछले POST ऑपरेशन से प्रतिक्रिया हो। उदाहरण के लिए आप कुछ दिनों के लिए जीमेल के साथ ईमेल भेज सकते हैं। वे एक ही विषय और शरीर हो सकते हैं, लेकिन दोनों ईमेल भेजे जाने चाहिए।
प्रॉक्सी कैशिंग के बारे में:
एक प्रॉक्सी HTTP सर्वर जो सर्वर पर आपके संदेश को आगे बढ़ाता है वह कभी भी कुछ नहीं बल्कि GET या HEAD अनुरोध को कैश करेगा।
सर्वर कैशिंग के बारे में:
डिफ़ॉल्ट रूप से एक सर्वर अपने कैश की जाँच के माध्यम से स्वचालित रूप से एक POST अनुरोध को संभाल नहीं सकता है। लेकिन निश्चित रूप से आपके आवेदन या ऐड-इन के लिए एक पोस्ट अनुरोध भेजा जा सकता है और आपके पास अपना कैश हो सकता है जिसे आप तब से पढ़ते हैं जब पैरामीटर समान होते हैं।
संसाधन को अमान्य करना:
HTTP 1.1 RFC 2616 S. 13.10 की जाँच से पता चलता है कि POST विधि को कैशिंग के लिए संसाधन को अमान्य करना चाहिए।
यदि आप POST प्रतिक्रिया को कैश करते हैं, तो यह वेब एप्लिकेशन की दिशा में होना चाहिए। इसका अर्थ है "जब तक इस विधि के जवाब उत्तरदायी नहीं होते हैं, जब तक कि प्रतिक्रिया में उपयुक्त कैश-नियंत्रण या शीर्ष लेख फ़ील्ड शामिल न हों।"
कोई भी सुरक्षित रूप से यह मान सकता है कि एप्लिकेशन, जो जानता है कि POST के नतीजे बेमतलब हैं या नहीं, यह निर्णय लेता है कि आवश्यक और उचित कैश कंट्रोल हेडर संलग्न करना है या नहीं। यदि कैशिंग का सुझाव देने वाले हेडर मौजूद हैं, तो एप्लिकेशन आपको बता रहा है कि POST वास्तविक रूप में, एक सुपर-जीईटी है; केवल बेकार और अप्रासंगिक की राशि के कारण POST का उपयोग आवश्यक था (आईडीआर के रूप में कैश कुंजी के रूप में) डेटा का उपयोग करने के लिए आवश्यक है।
इस धारणा के तहत GET का अनुसरण कैश से किया जा सकता है।
एक आवेदन जो कि आवश्यक और सही हेडर को कैचबल और गैर-कैशबल POST प्रतिक्रियाओं के बीच अंतर करने में विफल रहता है, किसी भी अवैध कैशिंग परिणामों के लिए गलत है।
उस ने कहा, कैश को हिट करने वाले प्रत्येक POST को सशर्त हेडर का उपयोग करके सत्यापन की आवश्यकता होती है। कैश की सामग्री को ताज़ा करने के लिए यह आवश्यक है ताकि किसी वस्तु के जीवनकाल के समाप्त होने तक अनुरोधों के जवाबों में पोस्ट के परिणामों को प्रतिबिंबित न किया जा सके।
मार्क नॉटिंघम ने विश्लेषण किया है जब किसी पोस्ट की प्रतिक्रिया को कैश करना संभव है। ध्यान दें कि कैशिंग का लाभ उठाने के लिए आने वाले अनुरोध GET या HEAD अनुरोध होने चाहिए। Http शब्दार्थ भी देखें
POSTs पहचान किए गए राज्य के प्रतिनिधित्व में सौदा नहीं करते हैं, 100 में से 99 बार। हालांकि, एक ऐसा मामला है जहां यह करता है; जब सर्वर यह कहने के लिए अपने रास्ते से बाहर चला जाता है कि यह POST प्रतिक्रिया उसके URI का एक प्रतिनिधित्व है, तो सामग्री-स्थान शीर्षलेख सेट करके जो अनुरोध URI के समान है। जब ऐसा होता है, तो POST प्रतिक्रिया उसी URI की GET प्रतिक्रिया की तरह होती है; इसे कैश और पुन: उपयोग किया जा सकता है - लेकिन भविष्य के लिए केवल GET अनुरोधों के लिए।
यदि आप सोच रहे हैं कि क्या आप पोस्ट अनुरोध को कैश कर सकते हैं, और उस प्रश्न के उत्तर पर शोध करने का प्रयास कर सकते हैं, तो आप सफल नहीं होंगे। "कैश पोस्ट अनुरोध" की खोज करते समय पहला परिणाम यह StackOverflow प्रश्न है।
जवाब इस बात का एक उलझन भरा मिश्रण है कि कैशिंग को कैसे काम करना चाहिए, RFC के अनुसार कैशिंग कैसे काम करता है, कैशिंग को RFC के अनुसार कैसे काम करना चाहिए, और कैशिंग व्यवहार में कैसे काम करता है। आइए आरएफसी के साथ शुरू करें, ब्राउज़र के वास्तव में काम करने के प्रदर्शन के माध्यम से चलें, फिर सीडीएन, ग्राफकलाइन और चिंता के अन्य क्षेत्रों के बारे में बात करें।
RFC के अनुसार, POST अनुरोधों को कैश को अमान्य करना चाहिए:
13.10 Invalidation After Updates or Deletions
..
Some HTTP methods MUST cause a cache to invalidate an entity. This is
either the entity referred to by the Request-URI, or by the Location
or Content-Location headers (if present). These methods are:
- PUT
- DELETE
- POST
यह भाषा बताती है कि POST अनुरोध अस्वीकार्य नहीं हैं, लेकिन यह सच नहीं है (इस मामले में)। कैश केवल पहले संग्रहीत डेटा के लिए अमान्य है। RFC (प्रकट होता है) स्पष्ट रूप से स्पष्ट करता है कि हाँ, आप POSTअनुरोधों को कैश कर सकते हैं:
9.5 POST
..
Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
retrieve a cacheable resource.
इस भाषा के बावजूद, उसी संसाधन के Cache-Controlबाद के POSTअनुरोधों को कैश नहीं करना चाहिए । POSTअनुरोध सर्वर को भेजे जाने चाहिए:
13.11 Write-Through Mandatory
..
All methods that might be expected to cause modifications to the
origin server's resources MUST be written through to the origin
server. This currently includes all methods except for GET and HEAD.
A cache MUST NOT reply to such a request from a client before having
transmitted the request to the inbound server, and having received a
corresponding response from the inbound server. This does not prevent
a proxy cache from sending a 100 (Continue) response before the
inbound server has sent its final reply.
उसका क्या अर्थ निकलता है? ठीक है, आप POSTअनुरोध को कैशिंग नहीं कर रहे हैं, आप संसाधन को कैशिंग कर रहे हैं।
POST प्रतिक्रिया निकाय को केवल उसी संसाधन के लिए GET अनुरोधों के लिए कैश किया जा सकता है। POST की प्रतिक्रिया में हेडर Locationया सेट करें कि Content-Locationसंचार किस संसाधन का प्रतिनिधित्व करता है। तो POST अनुरोध को कैश करने का एकमात्र तकनीकी रूप से मान्य तरीका, उसी संसाधन के लिए बाद में GET के लिए है।
सही उत्तर दोनों है:
यद्यपि RFC समान संसाधन के लिए कैशिंग अनुरोधों की अनुमति देता है, व्यवहार में, ब्राउज़र और CDN इस व्यवहार को लागू नहीं करते हैं, और आपको POST अनुरोधों को कैश करने की अनुमति नहीं देते हैं।
सूत्रों का कहना है:
निम्नलिखित उदाहरण को देखते हुए जावास्क्रिप्ट एप्लिकेशन (index.js):
const express = require('express')
const app = express()
let count = 0
app
.get('/asdf', (req, res) => {
count++
const msg = `count is ${count}`
console.log(msg)
res
.set('Access-Control-Allow-Origin', '*')
.set('Cache-Control', 'public, max-age=30')
.send(msg)
})
.post('/asdf', (req, res) => {
count++
const msg = `count is ${count}`
console.log(msg)
res
.set('Access-Control-Allow-Origin', '*')
.set('Cache-Control', 'public, max-age=30')
.set('Content-Location', 'http://localhost:3000/asdf')
.set('Location', 'http://localhost:3000/asdf')
.status(201)
.send(msg)
})
.set('etag', false)
.disable('x-powered-by')
.listen(3000, () => {
console.log('Example app listening on port 3000!')
})और निम्न उदाहरण वेब पेज (index.html) दिया:
<!DOCTYPE html>
<html>
<head>
<script>
async function getRequest() {
const response = await fetch('http://localhost:3000/asdf')
const text = await response.text()
alert(text)
}
async function postRequest(message) {
const response = await fetch(
'http://localhost:3000/asdf',
{
method: 'post',
body: { message },
}
)
const text = await response.text()
alert(text)
}
</script>
</head>
<body>
<button onclick="getRequest()">Trigger GET request</button>
<br />
<button onclick="postRequest('trigger1')">Trigger POST request (body 1)</button>
<br />
<button onclick="postRequest('trigger2')">Trigger POST request (body 2)</button>
</body>
</html>NodeJS स्थापित करें, एक्सप्रेस करें, और जावास्क्रिप्ट एप्लिकेशन शुरू करें। अपने ब्राउज़र में वेब पेज खोलें। ब्राउज़र व्यवहार का परीक्षण करने के लिए कुछ अलग परिदृश्य आज़माएँ:
इससे पता चलता है कि, भले ही आप हेडर सेट कर सकते हैं Cache-Controlऔर Content-Locationप्रतिक्रिया दे सकते हैं, लेकिन ब्राउज़र कैश को HTTP POST अनुरोध बनाने का कोई तरीका नहीं है।
ब्राउज़र व्यवहार कॉन्फ़िगर करने योग्य नहीं है, लेकिन यदि आप ब्राउज़र नहीं हैं, तो आप आवश्यक रूप से RFC के नियमों से बंधे नहीं हैं।
यदि आप एप्लिकेशन कोड लिख रहे हैं, तो POST अनुरोधों (pseudocode) को स्पष्ट रूप से कैशिंग करने से कुछ भी नहीं है।
if (cache.get('hello')) {
return cache.get('hello')
} else {
response = post(url = 'http://somewebsite/hello', request_body = 'world')
cache.put('hello', response.body)
return response.body
}CDN, परदे के पीछे और गेटवे को RFC का पालन करने की आवश्यकता नहीं है। उदाहरण के लिए, यदि आप अपने CDN के रूप में Fastly का उपयोग करते हैं, तो तेजी से आप POST अनुरोधों को कैश करने के लिए कस्टम VCL तर्क लिखने की अनुमति देता है ।
आपके POST अनुरोध को कैश किया जाना चाहिए या नहीं यह संदर्भ पर निर्भर करता है।
उदाहरण के लिए, आप POST का उपयोग करते हुए Elasticsearch या GraphQL से क्वेरी कर सकते हैं जहाँ आपकी अंतर्निहित क्वेरी बेकार है। उन मामलों में, उपयोग मामले के आधार पर प्रतिक्रिया को कैश करने के लिए यह समझ में नहीं आ सकता है या नहीं।
RESTful API में, POST अनुरोध आमतौर पर एक संसाधन बनाते हैं और इन्हें कैश नहीं किया जाना चाहिए। यह RFC POST की समझ भी है कि यह एक आदर्श ऑपरेशन नहीं है।
यदि आप ग्राफकलाइन का उपयोग कर रहे हैं और सीडीएन और ब्राउज़रों में HTTP कैशिंग की आवश्यकता है, तो विचार करें कि क्या GET विधि का उपयोग करके प्रश्न भेजने से POST के बजाय आपकी आवश्यकताएं पूरी होती हैं । एक चेतावनी के रूप में, अलग-अलग ब्राउज़रों और सीडीएन में अलग-अलग यूआरआई लंबाई सीमा हो सकती है, लेकिन ऑपरेशन सेफेलिस्टिंग (क्वेरी वाइटेलिस्ट), बाहरी-सामना करने वाले उत्पादन ग्राफ़कॉल ऐप के लिए सबसे अच्छा अभ्यास के रूप में, यूआरआई को छोटा कर सकता है।
यदि यह ऐसा कुछ है जो वास्तव में आपकी साइट पर डेटा नहीं बदलता है, तो यह एक GET अनुरोध होना चाहिए। यहां तक कि अगर यह एक रूप है, तो भी आप इसे एक अनुरोध के रूप में सेट कर सकते हैं। हालांकि, अन्य लोगों की तरह, आप एक POST के परिणामों को कैश कर सकते हैं, यह शब्दार्थ नहीं समझेगा क्योंकि परिभाषा के अनुसार एक POST डेटा बदल रहा है।
फायरफॉक्स के साथ 27.0 और httpfox के साथ, 19 मई 2014 को, मैंने इसकी एक पंक्ति देखी: 00: 03: 58.777 0.488 657 (393) POST (कैश) पाठ / html https ://users.jackiszhpfo/S4UP
स्पष्ट रूप से, पोस्ट विधि की प्रतिक्रिया बंद है, और यह https में भी है। अविश्वसनीय!
POST का उपयोग राज्य के अजाक्स में किया जाता है। POST के लिए कैश्ड रिस्पांस लौटाना संचार चैनल और संदेश प्राप्त करने के दुष्प्रभावों को हरा देता है। यह वेरी वेरी बैड है। यह नीचे ट्रैक करने के लिए एक वास्तविक दर्द भी है। के खिलाफ अत्यधिक अनुशंसा की जाती है।
एक तुच्छ उदाहरण एक संदेश होगा जो एक पक्ष प्रभाव के रूप में, आपके वेतन को मौजूदा सप्ताह में $ 10,000 का भुगतान करता है। तुम नहीं करना चाहते "ठीक है, यह के माध्यम से चला गया!" पृष्ठ पिछले सप्ताह कैश किया गया था। अन्य, अधिक जटिल वास्तविक दुनिया के मामलों में समान उल्लसितता होती है।