CORS preflight क्या है?
- जटिल request भेजने से पहले
OPTIONS के साथ पहले यह पूछना कि अनुमति है या नहीं
- लेकिन व्यवहार में ज़्यादातर requests को इसकी ज़रूरत पड़ती है (जैसे JSON/XML body हो, credentials शामिल हों, आदि)
- इसके बुरा होने की वजह यह है कि actual request में लगने वाला समय बढ़ जाता है
OPTIONS request को default रूप से cache नहीं किया जा सकता, इसलिए CDN भी आमतौर पर इसे handle नहीं करते और request server तक पहुँच जाती है- ये values client में cache होती हैं और default रूप से सिर्फ 5 सेकंड तक बनी रहती हैं
- यानी अगर webpage हर 10 सेकंड में API polling कर रहा है, तो preflight भी हर 10 सेकंड में एक बार होगा
- कई मामलों में यह browser client की API latency बढ़ा देता है, जिससे user के नज़रिए से performance आधी रह जाती है
- साथ ही यह API server पर बेकार का load डालता है और लागत बढ़ाता है
- खासकर अगर serverless हो तो और भी ज़्यादा। Lambda, Netlify Functions, Cloudflare Workers, Google Cloud Functions — सभी function invocation के हिसाब से charge करते हैं, इसलिए यह preflight भी उसमें शामिल होता है
preflight response को cache करने के तरीके
- browser में cache कर के, अनावश्यक समान preflight requests भेजे जाने से रोकना
- CDN layer में cache कर के, इन requests का जवाब actual backend server तक पहुँचाए बिना देना
Browsers के लिए CORS caching
- preflight response में यह header जोड़ें
Access-Control-Max-Age: 86400
- Firefox में 86400 (24 घंटे) तक संभव है, लेकिन Chromium-आधारित browsers में 7200 (2 घंटे) maximum value है
CDNs के लिए CORS caching
- CDN या proxy में caching के लिए ये headers जोड़ें
Cache-Control: public, max-age=86400
Vary: origin
- महत्वपूर्ण बात यह है कि
OPTIONS को default रूप से cache करने के लिए डिज़ाइन नहीं किया गया है, इसलिए यह standard नहीं है। लेकिन ज़्यादातर CDN इसे support करते हैं
Configuration उदाहरण
- AWS Lambda के साथ CORS caching
- Node.js में CORS caching
- Python में CORS caching
- Java Spring के साथ CORS caching
2 टिप्पणियां
मैं अभी इसी हिस्से को देख रहा था, और इसे बड़े मज़े से पढ़ा।
परफ़ॉर्मेंस बिल्कुल उलटी नहीं हुई -> परफ़ॉर्मेंस आधी हो गई