یک URL می‌تواند پاسخِ فارسی، انگلیسی یا پیش‌فرض داشته باشد. اگر کش فقط URL را کلید بگیرد، ممکن است پاسخِ زبانِ دیگر را انتخاب کند. هدرِ Vary فیلدهایِ درخواستِ مؤثر در انتخابِ نسخه را نام می‌برد؛ برابریِ این فیلدها با درخواستِ اصلیِ هر پاسخ باید کنترل شود. این مثال، انتخابِ نسخهٔ عمومی را در حافظه اجرا می‌کند، نه تنظیمِ CDN یا کشِ سایتِ واقعی.
چهار پاسخِ یک نشانی
نشانیِ ساختگی /public/guide چهار رکورد دارد: درخواستِ Accept-Language:fa با پاسخِ فارسی، en با انگلیسی، درخواستِ فاقدِ هدر با پاسخِ پیش‌فرض، و درخواستِ دارایِ هدرِ خالی با پاسخِ مستقلِ دیگر. همهٔ پاسخ‌ها Vary:Accept-Language دارند؛ پاسخِ پیش‌فرض هم این قرارداد را حذف نکرده است.
در این مدل، پاسخ‌ها از قبل عمومی، قابلِ ذخیره، تازه و مجاز برای GET اعتبارسنجی شده‌اند. انتخابِ کلید، هیچ‌یک از این پیش‌شرط‌ها را تولید نمی‌کند. تاریخ‌ها به‌ترتیبِ معتبرِ ازپیش‌تعیین‌شده‌اند؛ این کد parser Date یا محاسبهٔ Age نیست.
نامِ هدر و مقدارِ آن دو قراردادند
نامِ فیلد با حروفِ بزرگ و کوچک یکسان مقایسه می‌شود. در profile محدودِ ما، مقدارِ Accept-Language و Accept-Encoding نیز به حروفِ کوچک تبدیل و فقط فاصلهٔ ابتدا و انتهایِ مجاز حذف می‌شود. برای فیلدِ افزودهٔ X-Edition، مقدارِ A با a یکسان فرض نمی‌شود.
این نرمال‌سازی parser عمومیِ HTTP نیست؛ qvalue، مرتب‌کردنِ ترجیح‌ها، ترکیبِ چند خطِ هدر یا تحلیلِ کاملِ مذاکرهٔ محتوا اجرا نشده‌اند. اگر مقداری در این قرارداد تطبیق نکند، کد نمی‌گوید در همهٔ پیاده‌سازی‌هایِ استانداردِ HTTP حتماً نامعادل است.
نبودِ هدر با هدرِ خالی فرق دارد
| درخواستِ تازهٔ همان URL | رکوردِ انتخاب‌شده |
|---|---|
| accept-language با مقدارِ FA و فاصلهٔ بیرونی | فارسی، شناسه ۱ |
| Accept-Language:en | انگلیسی، شناسه ۲ |
| بدونِ هدر | پیش‌فرضِ فاقدِ ترجیح، شناسه ۳ |
| هدر با مقدارِ خالی | رکوردِ خالیِ صریح، شناسه ۴ |
| Accept-Language:de | هیچ رکوردِ مطابق |
برای پنج درخواستِ این جدول، خروجی با مرجعِ مستقلِ tuple «وجودِ فیلد، مقدار» مقایسه می‌شود. نسخهٔ عمداً غلطِ URL-only برای درخواستِ en متنِ فارسیِ نخست را برمی‌گرداند؛ بنابراین خطا فقط کاهشِ hit-rate نیست، انتخابِ بدنهٔ ناسازگار است.
ستاره، حتی با درخواستِ برابر match نیست
رکوردِ دارایِ Vary:* همیشه در matcher این تمرین شکست می‌خورد. این نتیجه را به منعِ مطلقِ هر استفادهٔ دوباره تعمیم نمی‌دهیم؛ RFC۴٫۱ دربارهٔ استفاده بدونِ revalidation در صورتِ عدمِ تطبیق صحبت می‌کند. کدِ ما مسیرِ revalidation یا ارتباط با origin ندارد و در نبودِ match، فقط None می‌دهد.
اگر دو پاسخِ تازه با همان فیلدها مطابق باشند، نسخهٔ دارایِ Date جدیدتر انتخاب می‌شود؛ در شاهدِ مستقل، رکورد ۶ جایِ ۱ را می‌گیرد. ترتیبِ تصادفیِ فهرست مرجعِ انتخاب نیست. ترجیحِ مبتنی بر q در این سیاست پیاده نشده است.
تطبیقِ Vary، تازگی یا مجوز نمی‌سازد
در شاهدِ رکوردِ stale، حتی با هدرِ برابر پاسخ کنار گذاشته می‌شود چون پیش‌شرطِ استفاده برقرار نیست؛ هدرِ برابر آن را تازه نمی‌کند. در موردِ دو فیلدِ نام‌برده، هم زبان و هم X-Edition باید مطابق باشند. نشانیِ متفاوت نیز پاسخِ یک URL دیگر را انتخاب نمی‌کند.
شش ورودیِ نامعتبر، از نام‌هایِ تکراری پس از casefold و CRLF تا مقدارِ غیرمتن، هدرِ بیش از ۱۲۸ نویسه، بیش از ۸ رکورد و نشانیِ بیرون از/public/رد می‌شوند. این سقف‌ها و namespace برای آزمایشِ محلی‌اند، نه محدودیتِ عمومیِ استاندارد.
کشِ پاسخِ مدل نسخهٔ منبع، مجوز و ابطال را می‌سنجد؛ اینجا matcher نسخه‌هایِ HTTP رویِ یک نشانی اجرا می‌شود. If-Match نوشتنِ شرطی و LRU اخراجِ رکورد را توضیح می‌دهد. ادامه در مبانی هوش مصنوعی؛ کشِ شخصی، سرور، ترافیک یا صرفه‌جوییِ واقعیِ اپرا آزمایش نشده است.
فایل تمرین و منبع
کد کاملِ تمرینِ مستقل و کنترل‌ها؛ Python · ورودی و تمامِ خروجیِ اجرای واقعی؛ JSON
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.