CORS preflight คืออะไร?
- คือการส่งคำขอด้วย
OPTIONS ก่อน เพื่อขอตรวจสอบสิทธิ์ก่อนส่งคำขอที่ซับซ้อนจริง
- แต่ในทางปฏิบัติ คำขอส่วนใหญ่ก็มักต้องใช้สิ่งนี้อยู่แล้ว (เช่น มี body แบบ JSON/XML หรือมี credentials เป็นต้น)
- เหตุผลที่มันไม่ดีคือทำให้เวลาที่ใช้กับคำขอจริงเพิ่มขึ้น
- โดยพื้นฐานแล้วคำขอ
OPTIONS ไม่สามารถแคชได้ ดังนั้น CDN ส่วนใหญ่ก็มักไม่จัดการ และทำให้คำขอวิ่งไปถึงเซิร์ฟเวอร์
- ค่าเหล่านี้จะถูกแคชฝั่งไคลเอนต์ และโดยปกติจะเก็บไว้เพียง 5 วินาที
- นั่นคือถ้าเว็บเพจมีการ polling API ทุก 10 วินาที ก็จะมี preflight เกิดขึ้นหนึ่งครั้งทุก 10 วินาที
- ในหลายกรณี สิ่งนี้เพิ่ม API latency ของเบราว์เซอร์ไคลเอนต์ ทำให้ในมุมผู้ใช้ประสิทธิภาพลดลงครึ่งหนึ่ง
- อีกทั้งยังเพิ่มภาระที่ไม่จำเป็นให้กับ API server และทำให้ต้นทุนสูงขึ้น
- โดยเฉพาะถ้าเป็น serverless ยิ่งชัดเจนขึ้นไปอีก เพราะ Lambda, Netlify Functions, Cloudflare Workers, Google Cloud Functions ล้วนคิดค่าบริการตามจำนวนครั้งที่เรียกใช้ฟังก์ชัน และ preflight นี้ก็นับรวมด้วย
วิธีแคชการตอบกลับของ preflight
- แคชในเบราว์เซอร์ เพื่อไม่ให้ส่งคำขอ preflight เดิมที่ไม่จำเป็นซ้ำอีก
- แคชที่ชั้น CDN เพื่อให้ตอบกลับคำขอเหล่านี้ได้โดยไม่ต้องให้ backend server จริงเป็นผู้จัดการ
CORS caching for browsers
- เพิ่มเฮดเดอร์ต่อไปนี้ในคำตอบของ preflight:
Access-Control-Max-Age: 86400
- Firefox ตั้งได้ถึง 86400 (24 ชั่วโมง) แต่เบราว์เซอร์สาย Chromium จำกัดค่าสูงสุดไว้ที่ 7200 (2 ชั่วโมง)
CORS caching for CDNs
- เพื่อให้ CDN หรือพร็อกซีแคชได้ ให้เพิ่มเฮดเดอร์ต่อไปนี้
Cache-Control: public, max-age=86400
Vary: origin
- ประเด็นสำคัญคือ
OPTIONS ไม่ได้ถูกกำหนดให้แคชได้โดยปริยาย ดังนั้นจึงไม่ใช่มาตรฐาน แต่ CDN ส่วนใหญ่รองรับ
ตัวอย่างการตั้งค่า
- Caching CORS with AWS Lambda
- Caching CORS in Node.js
- Caching CORS in Python
- Caching CORS with Java Spring
2 ความคิดเห็น
กำลังดูส่วนนี้อยู่พอดี อ่านแล้วสนุกดีครับ
ประสิทธิภาพจากตรงกันข้าม -> ประสิทธิภาพลดลงครึ่งหนึ่ง