Un file salvato non è ancora un download verificato

Un report.xlsx ipotetico pesa 8 KB e si apre come pagina di accesso. Il programma ha salvato un file correttamente, ma non ha mai ottenuto il foglio di calcolo previsto. Il nome del file viene scelto localmente; non è prova di ciò che è arrivato.

Rendete l'accettazione un passaggio separato prima di pubblicare il download temporaneo:

1. Richiedete un trasferimento riuscito e lo stato di risposta atteso. Conservate l'errore invece di considerare completi i byte scritti prima di esso.
2. Confrontate il contenuto con il tipo di artefatto atteso. Una pagina di accesso o di filtro può restituire 200. Il Content-Type può essere errato, e un prefisso HTML in un foglio di calcolo è un avviso da indagare. Un file che inizia con una riga di stato HTTP indica invece un incorniciamento della risposta grezza.
3. Convalidate tutti i byte salvati rispetto a un checksum o a una firma attendibile, quando disponibili. Solo dopo il superamento dei controlli richiesti l'applicazione dovrebbe pubblicare o usare il file finale.

Calcolare un hash senza un valore atteso identifica solo i byte ricevuti. Un checksum non firmato recuperato dallo stesso percorso non attendibile può condividere la debolezza dell'artefatto; usate un'aspettativa attendibile indipendente.

Fate attenzione anche ai confronti di dimensione. Un client HTTP può decodificare la codifica dei contenuti durante la lettura, quindi la lunghezza del file risultante può legittimamente differire da un'intestazione che descrive il messaggio codificato. Confrontate l'aspettativa dell'editore con la rappresentazione effettivamente salvata.

Se un tentativo fallisce, conservate l'output temporaneo solo per una ripresa deliberata oppure scartatelo. Lasciare byte incompleti nel percorso finale costringe il programma successivo a indovinare se sono utilizzabili.