در دنیای اینترنت و وب، استفاده از کشینگ HTTP یکی از روش‌های پراستفاده برای بهبود عملکرد و سرعت دسترسی کاربران به محتوای وب است. کشینگ به ما کمک می‌کند تا منابع پویا و استاتیک سایت‌ها را به صورت موقت ذخیره کنیم و با استفاده مجدد از این منابع ذخیره شده، سرعت بارگذاری صفحات را افزایش دهیم. یکی از استانداردهایی که به این زمینه اختصاص دارد، RFC 9111 است که به خصوص به بحث کشینگ پاسخ‌های احراز هویت شده می‌پردازد.
یکی از چالش‌های کشینگ در درخواست‌های احراز هویت شده، مسئله امنیت و حفظ حریم خصوصی است. چرا که این درخواست‌ها معمولاً حاوی اطلاعات حساس و شخصی هستند و ذخیره‌سازی آن‌ها ممکن است به خطر دسترسی غیرمجاز منجر شود. استانداردهای جدید، روش‌هایی را برای ذخیره سازی امن این نوع پاسخ‌ها تعریف می‌کنند.
در RFC 9111، تأکید شده است که سرورهای وب مشخص کنند که آیا پاسخ احراز هویت شده برای کش شدن امن است یا خیر. این کار معمولاً با تنظیم هدرهای HTTP مانند Cache-Control انجام می‌شود. این هدرها می‌توانند مشخص کنند که پاسخ‌ها تنها برای مدت زمان معینی کش شوند یا اصلاً کش نشوند.
به طور خلاصه، RFC 9111 به ما کمک می‌کند تا در هنگام کشینگ درخواست‌های احراز هویت شده، بتوانیم هم به عملکرد بهینه سیستمی دست یابیم و هم امنیت داده‌ها و حریم خصوصی کاربران را حفظ کنیم. این امر به میزان زیادی به بشریت کمک می‌کند تا تجربه کاربری بهتری را در مرورگرهای خود تجربه کنند.
نمونه کد: تنظیم کش در درخواست‌های احراز هویت شده
GET /protected/resource HTTP/1.1
Host: example.com
Authorization: Bearer <token>
Cache-Control: private, max-age=3600
توضیحات خط به خط:
GET /protected/resource HTTP/1.1: این خط نشان‌دهنده‌ی درخواست نوع GET برای دسترسی به منابع محافظت شده است.
Host: example.com: در اینجا، آدرس میزبان سرور که باید به آن متصل شویم مشخص شده است.
Authorization: Bearer <token>: این خط شامل اطلاعات لازم برای احراز هویت است که به صورت Bearer Token ارائه می‌شود.
Cache-Control: private, max-age=3600: این هدر نشان می‌دهد که پاسخ فقط برای استفاده‌ی کاربر فعال کش می‌شود و به مدت ۳۶۰۰ ثانیه (۱ ساعت) معتبر است.