Download-URL'en er korrekt, men en delt proxy har stadig et lagret svar. Hvis handlingen kræver et svar, der er valideret hos oprindelsen, skal du lægge det krav på anmodningen:

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)

Dette uddrag forudsætter, at applikationen ejer en binær outputstrøm og leverer en HTTPS download_url. For at prøve en tilladt offentlig download uden proxy-godkendelse kan du bruge en HTTP-endpointkandidat fra HTTP-proxylisten i openeren; anmodningens cache-krav forbliver det samme. Det bevarer resursens oprindelige URL, mens det beder caches på anmodningsstien om at validere før genbrug.

Validering kan genbruge de lagrede bytes

En compliant cache, der modtager no-cache, kan ikke opfylde denne anmodning fra et lagret svar uden vellykket validering hos oprindelsen. Oprindelsen kan bekræfte, at den lagrede repræsentation stadig er gyldig, så handlingen behøver ikke gensende en uændret fil fra oprindelsen.

En anmodnings max-age=0 udtrykker en aldersgrænse. Det er nyttigt, når applikationen vil have et svar, der ikke er ældre end den grænse, men det er ikke et forbud mod lagring. Et svar, der lige er genereret, kan opfylde det.

Tilføjelse af en tilfældig query-parameter beder om en anden mål-URI. Det kan give en ny cache-post eller endda ændre applikationens svar. Brug kun en query-parameter, når den er en del af resursens tilsigtede interface.

For almindelig HTTPS CONNECT kan tunnel-proxyen ikke se denne header inde i TLS. Politikken kan stadig nå oprindelsen og de caches, der håndterer den dekrypterede HTTP-udveksling. Kontroller, hvor det lagrede svar faktisk ligger, før du tilskriver det tunnelen.

Relaterede artikler