En lagret fil er ikke en verifisert nedlasting ennå
Før du publiserer eller bruker den, må du kontrollere at en nedlasting gjennom proxyen inneholder den forventede filen og ikke en innloggingsside eller en ufullstendig respons.
En tenkt report.xlsx er 8 KB og åpner seg som en innloggingsside. Programmet lagret filen uten feil, men fikk aldri regnearket det var ment å hente. Filnavnet blir valgt lokalt og sier ingenting om hva som faktisk ankom.
La godkjenningen være et eget trinn før den midlertidige nedlastingen publiseres:
- Still krav om vellykket overføring og forventet svarbstatus. Behold feilen i stedet for å behandle bytene som ble skrevet før den, som komplette.
- Sammenlign innholdet med den filtypen du forventer. En innloggings- eller filterside kan svare med 200. Content-Type kan være gal, og en HTML-fortegn i et regneark er et varsel som må undersøkes. En fil som starter med en HTTP-statuslinje, tyder derimot på rå responsinnramming.
- Kontroller alle lagrede byter mot en pålitelig sjekksum eller signatur når slik finnes. Applikasjonen bør først publisere eller ta i bruk den endelige filen etter at de påkrevde kontrollene er bestått.
Å regne ut en hash uten en forventet verdi viser bare hvilke byter du mottok. En usignert sjekksum som hentes over den samme upålitelige veien, kan dele filens svakhet; bruk en uavhengig pålitelig forventning.
Vær også oppmerksom på størrelsessammenligninger. En HTTP-klient kan dekode innholdskodingen mens den leser, slik at fillengden som oppstår, kan avvike helt legitimt fra en header som beskriver den kodede meldingen. Sammenlign utgiverens forventning med den representasjonen som faktisk ble lagret.
Dersom et forsøk mislykkes, skal du bare beholde den midlertidige utskriften for en bevisst gjenopptakelse, ellers kaste den. Ufullstendige byter som blir liggende på den endelige stien, tvinger det neste programmet til å gjette om de kan brukes.