أعد التحقق من تنزيل عبر وكيل باستخدام Cache-Control: no-cache

عنوان URL للتنزيل صحيح، لكن الوكيل المشترك لا يزال يحتفظ باستجابة مخزّنة. إذا كانت العملية تحتاج إلى استجابة يُعاد التحقق منها مع الأصل، فضع هذا الشرط على الطلب:

from urllib.request import ProxyHandler, Request, build_opener
import shutil

opener = build_opener(ProxyHandler({
    "https": "http://proxy.example:8080",
}))
request = Request(download_url, headers={"Cache-Control": "no-cache"})
with opener.open(request, timeout=15) as response:
    shutil.copyfileobj(response, output)

تفترض هذه القطعة أن التطبيق يملك دفق إخراج ثنائيًا ويوفّر download_url من نوع HTTPS. لتجربة تنزيل عام مسموح به دون مصادقة وكيل، استخدم أحد مرشّحي نقاط النهاية HTTP من قائمة وكلاء HTTP في الفاتح؛ ويبقى شرط التخزين المؤقت في الطلب كما هو. فهو يحافظ على عنوان URL الأصلي للمورد بينما يطلب من ذاكرات التخزين المؤقت على مسار الطلب أن تتحقق قبل إعادة الاستخدام.

يمكن لإعادة التحقق إعادة استخدام البايتات المخزّنة

لا تستطيع ذاكرة تخزين مؤقت مطابقة تستقبل no-cache تلبية هذا الطلب من استجابة مخزّنة دون تحقق ناجح مع الأصل. ويمكن للأصل أن يؤكد أن التمثيل المخزّن ما زال صالحًا، فلا تحتاج العملية إلى إعادة إرسال ملف لم يتغير من الأصل.

يعبّر max-age=0 في الطلب عن حدٍّ للعمر. وهو مفيد عندما يريد التطبيق استجابة لا يتجاوز عمرها ذلك الحد، لكنه ليس منعًا للتخزين. فالاستجابة التي أُنشئت للتو يمكنها تلبيته.

إضافة معامل استعلام عشوائي تطلب URI هدفًا مختلفًا. وقد يُنتج ذلك إدخالًا آخر في ذاكرة التخزين المؤقت أو حتى يغيّر استجابة التطبيق. لا تستخدم معامل استعلام إلا عندما يكون جزءًا من الواجهة المقصودة للمورد.

بالنسبة إلى HTTPS CONNECT العادي، لا يستطيع وكيل النفق رؤية هذا الترويسة داخل TLS. ومع ذلك يمكن للسياسة أن تصل إلى الأصل وإلى ذاكرات التخزين المؤقت التي تتعامل مع تبادل HTTP المفكوك. تحقق من المكان الذي تعيش فيه الاستجابة المخزّنة فعليًا قبل أن تنسبها إلى النفق.