Revalider un téléchargement via un proxy avec Cache-Control: no-cache

Demandez une réponse validée sans changer l'URL de téléchargement ni confondre la revalidation avec une interdiction de stockage.

L'URL de téléchargement est correcte, mais un proxy partagé possède encore une réponse stockée. Si l'opération a besoin d'une réponse validée auprès de l'origine, placez cette exigence sur la requête :

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)

Cet extrait suppose que l'application possède un flux de sortie binaire et fournit un download_url HTTPS. Pour essayer un téléchargement public autorisé sans authentification proxy, utilisez un candidat de point de terminaison HTTP de la liste de proxys HTTP dans l'opener ; l'exigence de cache de la requête reste la même. Il conserve l'URL d'origine de la ressource tout en demandant aux caches du chemin de la requête de valider avant réutilisation.

La validation peut réutiliser les octets stockés

Un cache conforme qui reçoit no-cache ne peut pas satisfaire cette requête à partir d'une réponse stockée sans une validation réussie auprès de l'origine. L'origine peut confirmer que la représentation stockée reste valide, donc l'opération n'a pas besoin de retransmettre un fichier inchangé depuis l'origine.

Le max-age=0 d'une requête exprime une limite d'âge. Il est utile lorsque l'application veut une réponse pas plus ancienne que cette limite, mais ce n'est pas une interdiction de stockage. Une réponse qui vient d'être générée peut la satisfaire.

Ajouter un paramètre de requête aléatoire demande un autre URI cible. Cela peut produire une autre entrée de cache ou même modifier la réponse de l'application. N'utilisez un paramètre de requête que lorsqu'il fait partie de l'interface prévue de la ressource.

Pour un HTTPS CONNECT ordinaire, le proxy tunnel ne peut pas voir cet en-tête à l'intérieur de TLS. La politique peut néanmoins atteindre l'origine et les caches qui traitent l'échange HTTP déchiffré. Vérifiez où vit réellement la réponse stockée avant de l'attribuer au tunnel.

Articles similaires