Un fichier enregistré n'est pas encore un téléchargement vérifié

Un report.xlsx hypothétique fait 8 KB et s'ouvre comme une page de connexion. Le programme a bien enregistré un fichier, mais il n'a jamais obtenu le tableur prévu. Un nom de fichier est choisi localement ; ce n'est pas une preuve de ce qui est arrivé.

Faites de l'acceptation une étape distincte avant de publier le téléchargement temporaire :

1. Exigez un transfert réussi et le statut de réponse attendu. Conservez l'erreur au lieu de considérer comme complets les octets écrits avant elle.
2. Comparez le contenu au type d'artefact attendu. Une page de connexion ou de filtrage peut renvoyer 200. Le Content-Type peut être erroné, et un préfixe HTML dans un tableur est un avertissement à examiner. Un fichier commençant par une ligne de statut HTTP indique plutôt un encadrement de réponse brut.
3. Validez l'intégralité des octets enregistrés par rapport à une somme de contrôle ou une signature de confiance lorsqu'elle est disponible. Ce n'est qu'après la réussite des vérifications requises que l'application devrait publier ou utiliser le fichier final.

Calculer un hachage sans valeur attendue n'identifie que les octets reçus. Une somme de contrôle non signée récupérée par le même chemin non fiable peut partager la faiblesse de l'artefact ; utilisez une attente de confiance indépendante.

Prenez garde aussi aux comparaisons de taille. Un client HTTP peut décoder l'encodage du contenu pendant la lecture, si bien que la longueur du fichier obtenu peut légitimement différer d'un en-tête décrivant le message encodé. Comparez l'attente de l'éditeur à la représentation réellement enregistrée.

Si une tentative échoue, ne conservez la sortie temporaire que pour une reprise délibérée, ou jetez-la. Laisser des octets incomplets au chemin final oblige le programme suivant à deviner s'ils sont utilisables.