პროქსის გავლით ჩამოტვირთვის ხელახალი ვალიდაცია 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)

ეს ფრაგმენტი ვარაუდობს, რომ აპლიკაციას აქვს ბინარული გამომავალი ნაკადი და აწვდის HTTPS download_url-ს. ნებადართული საჯარო ჩამოტვირთვის პროქსის ავთენტიფიკაციის გარეშე მოსაცდელად გამოიყენეთ HTTP ბოლო წერტილის კანდიდატი HTTP პროქსების სიიდან opener-ში; მოთხოვნის ქეშის მოთხოვნა იგივე რჩება. ის ინახავს რესურსის თავდაპირველ URL-ს და ამავდროულად სთხოვს მოთხოვნის გზაზე მყარ ქეშებს ვალიდაცია ხელახალი გამოყენების წინ.

ვალიდაციამ შეიძლება ხელახლა გამოიყენოს შენახული ბაიტები

no-cache-ის მიმღები შესაბამისი ქეში ვერ დააკმაყოფილებს ამ მოთხოვნას შენახული პასუხიდან წყაროსთან წარმატებული ვალიდაციის გარეშე. წყაროს შეუძლია დაადასტუროს, რომ შენახული წარდგენა კვლავ ძალაშია, ამიტომ ოპერაციას არ სჭირდება უცვლელი ფაილის ხელახლა გაგზავნა წყაროდან.

მოთხოვნის max-age=0 გამოხატავს ასაკობრივ ზღვარს. ეს სასარგებლოა, როცა აპლიკაციას სურს პასუხი, რომელიც ამ ზღვარზე ძველი არ არის, მაგრამ ეს შენახვის აკრძალვა არ არის. ახლახან შექმნილ პასუხს შეუძლია მისი დაკმაყოფილება.

შემთხვევითი მოთხოვნის პარამეტრის დამატება ითხოვს სხვა სამიზნე URI-ს. ამან შეიძლება შექმნას სხვა ქეშის ჩანაწერი ან თვით აპლიკაციის პასუხიც კი შეცვალოს. მოთხოვნის პარამეტრი გამოიყენეთ მხოლოდ მაშინ, როცა ის რესურსის განკუთვნილი ინტერფეისის ნაწილია.

ჩვეულებრივი HTTPS CONNECT-ისთვის გვირაბის პროქსი ვერ ხედავს ამ სათაურს TLS-ის შიგნით. პოლიტიკა მაინც შეიძლება მიაღწიოს წყაროს და ქეშებს, რომლებიც ამუშავებენ გაშიფრულ HTTP გაცვლას. სანამ შენახულ პასუხს გვირაბს მიაწერთ, შეამოწმეთ სად ცხოვრობს ის სინამდვილეში.