Einen Download über einen Proxy mit Cache-Control: no-cache revalidieren

Fordern Sie eine validierte Antwort an, ohne die Download-URL zu ändern oder Revalidierung mit einem Speicherverbot zu verwechseln.

Die Download-URL ist korrekt, aber ein gemeinsamer Proxy hat noch eine gespeicherte Antwort. Wenn der Vorgang eine beim Ursprung validierte Antwort benötigt, legen Sie diese Anforderung auf die Anfrage:

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)

Dieses Fragment setzt voraus, dass die Anwendung einen binären Ausgabestream besitzt und eine HTTPS-download_url liefert. Um einen erlaubten öffentlichen Download ohne Proxy-Authentifizierung zu testen, verwenden Sie im Opener einen HTTP-Endpunkt-Kandidaten aus der HTTP-Proxy-Liste; die Cache-Anforderung der Anfrage bleibt gleich. Sie behält die ursprüngliche Ressourcen-URL bei und bittet Caches auf dem Anfragepfad, vor der Wiederverwendung zu validieren.

Die Validierung kann die gespeicherten Bytes wiederverwenden

Ein konformer Cache, der no-cache empfängt, kann diese Anfrage nicht aus einer gespeicherten Antwort erfüllen, ohne erfolgreich beim Ursprung zu validieren. Der Ursprung kann bestätigen, dass die gespeicherte Repräsentation weiterhin gültig ist, sodass der Vorgang eine unveränderte Datei nicht erneut vom Ursprung übertragen muss.

Ein max-age=0 in einer Anfrage drückt eine Altersgrenze aus. Es ist nützlich, wenn die Anwendung eine Antwort möchte, die nicht älter als diese Grenze ist, aber es ist kein Verbot der Speicherung. Eine gerade erzeugte Antwort kann es erfüllen.

Das Hinzufügen eines zufälligen Query-Parameters fragt eine andere Ziel-URI an. Das kann einen weiteren Cache-Eintrag erzeugen oder sogar die Antwort der Anwendung verändern. Verwenden Sie einen Query-Parameter nur, wenn er Teil der vorgesehenen Schnittstelle der Ressource ist.

Bei gewöhnlichem HTTPS CONNECT kann der Tunneling-Proxy diesen Header innerhalb von TLS nicht sehen. Die Richtlinie kann den Ursprung und die Caches, die den entschlüsselten HTTP-Austausch bearbeiten, dennoch erreichen. Prüfen Sie, wo die gespeicherte Antwort tatsächlich liegt, bevor Sie sie dem Tunnel zuschreiben.

Ähnliche Artikel