رشته پرس‌وجو پاسخ را تحت قواعد مدرن HTTP غیرقابل‌کش نمی‌کند. منبعی عمومی مانند /catalog?page=2 می‌تواند تازگی موردنظرش را مستقیماً اعلام کند:

Cache-Control: public, max-age=60

این یک سیاست نمونه برای محتوای عمومی است. پاسخ هنوز باید سایر الزامات قابل‌کش‌بودن را برآورده کند. نتایج شخصی‌سازی‌شده نباید فقط به این دلیل که گرداننده پروکسی نرخ برخورد بهتری می‌خواهد، کش مشترک پیدا کنند.

پرس‌وجو بخشی از URI هدف است که در کلید کش استفاده می‌شود. صفحه 2 و صفحه 3 درخواست‌های متفاوتی هستند. حذف پرس‌وجو برای شبیه کردن URLهایشان می‌تواند یک نتیجه را به جای دیگری سرو کند؛ اما نتایج را معادل نمی‌کند.

محدودیت قدیمی‌تر HTTP بر تازگی اکتشافی برای URLهای دارای پرس‌وجو پس از آنکه ضعیف اجراشده ثابت شد حذف شد. تازگی صریح از اتکا به حدس کش پرهیز می‌کند، در حالی که قواعد محلی پروکسی همچنان می‌توانند URLهای خاصی را کنار بگذارند.

ترافیک معمولی HTTPS CONNECT منبع و سیاست کش آن را داخل TLS باقی می‌گذارد. پروکسی پیشرو تونل‌زن برای آن صفحه‌ها کش شیء به دست نمی‌آورد فقط به این دلیل که URL از پرس‌وجو استفاده می‌کند.

مقالات مرتبط