CORS preflight là gì?
- Trước khi gửi một yêu cầu phức tạp, trình duyệt sẽ gửi
OPTIONS trước để hỏi xem có quyền hay không
- Nhưng trên thực tế, phần lớn các yêu cầu đều cần bước này (ví dụ có body JSON/XML hoặc bao gồm credentials, v.v.)
- Điều này không tốt vì làm tăng thời gian cho yêu cầu thực tế
- Yêu cầu
OPTIONS về cơ bản không thể được cache mặc định, nên các CDN cũng thường không xử lý cache và yêu cầu sẽ đi tới tận máy chủ
- Các giá trị này được cache ở phía client và mặc định chỉ giữ trong 5 giây
- Tức là nếu trang web polling API mỗi 10 giây, thì preflight cũng sẽ diễn ra một lần mỗi 10 giây
- Trong nhiều trường hợp, nó làm tăng độ trễ API ở phía trình duyệt, khiến hiệu năng mà người dùng cảm nhận được giảm một nửa
- Ngoài ra còn tạo gánh nặng không cần thiết cho máy chủ API và làm tăng chi phí
- Đặc biệt nếu dùng serverless thì càng rõ hơn. Lambda, Netlify Functions, Cloudflare Workers, Google Cloud Functions đều tính phí theo mỗi lần gọi hàm, và preflight này cũng được tính vào đó
Cách cache phản hồi preflight
- Cache ở trình duyệt để tránh gửi các yêu cầu preflight giống nhau không cần thiết
- Cache ở lớp CDN để các yêu cầu này được phản hồi mà không cần backend thực tế xử lý
CORS caching for browsers
- Thêm header sau vào phản hồi preflight:
Access-Control-Max-Age: 86400
- Firefox cho phép tới 86400 (24 giờ), nhưng các trình duyệt dựa trên Chromium có giá trị tối đa là 7200 (2 giờ)
CORS caching for CDNs
- Để cache ở CDN hoặc proxy, thêm các header sau
Cache-Control: public, max-age=86400
Vary: origin
- Điều quan trọng là
OPTIONS mặc định không được thiết kế để cache, nên đây không phải là tiêu chuẩn. Tuy vậy, hầu hết CDN đều hỗ trợ
Ví dụ cấu hình
- Caching CORS with AWS Lambda
- Caching CORS in Node.js
- Caching CORS in Python
- Caching CORS with Java Spring
2 bình luận
Đúng lúc tôi cũng đang xem phần này nên đã đọc rất thú vị.
Hiệu năng từ hoàn toàn ngược lại -> hiệu năng giảm một nửa