Një skedar i ruajtur nuk është ende një shkarkim i verifikuar
Para se ta publikoni ose përdorni, kontrolloni që një shkarkim përmes përfaqësuesit përmban artefaktin e pritur, jo një faqe autentikimi ose një përgjigje të paplotë.
Një report.xlsx hipotetik është 8 KB dhe hapet si faqe hyrjeje. Programi ruajti me sukses një skedar, por nuk e mori kurrë tabelën e synuar. Emri i skedarit zgjidhet lokalisht; nuk është provë e asaj që mbërriti.
Bëjeni pranimin një hap të veçantë përpara publikimit të shkarkimit të përkohshëm:
- Kërkoni një transferim të suksesshëm dhe statusin e pritur të përgjigjes. Ruani gabimin në vend që t'i trajtoni bajtët e shkruar para tij si të plotë.
- Krahasoni përmbajtjen me llojin e pritur të artefaktit. Një faqe hyrjeje ose filtri mund të kthejë 200. Content-Type mund të jetë i gabuar, dhe një parashtesë HTML në një tabelë është një paralajmërim që kërkon hetim. Një skedar që fillon me një rresht statusi HTTP tregon më mirë një kornizim të papërpunuar të përgjigjes.
- Validoni të gjithë bajtët e ruajtur kundrejt një checksum ose nënshkrimi të besuar kur është i disponueshëm. Aplikacioni duhet ta publikojë ose përdorë skedarin përfundimtar vetëm pasi të kalojnë kontrollet e kërkuara.
Llogaritja e një hash pa një vlerë të pritur identifikon vetëm bajtët që morët. Një checksum i panënshkruar i marrë përmes të njëjtës rrugë të pabesueshme mund të ndajë dobësinë e artefaktit; përdorni një pritje të pavarur të besuar.
Kini kujdes edhe me krahasimet e madhësisë. Një klient HTTP mund të dekodojë kodimin e përmbajtjes gjatë leximit, kështu që gjatësia e skedarit që rezulton mund të ndryshojë në mënyrë legjitime nga një kokë që përshkruan mesazhin e koduar. Krahasoni pritjen e botuesit me paraqitjen që është ruajtur në të vërtetë.
Nëse një përpjekje dështon, mbajeni daljen e përkohshme vetëm për një rifillim të qëllimshëm ose hidheni atë. Lënia e bajtëve të paplotë në rrugën përfundimtare e detyron programin tjetër të hamendësojë nëse janë të përdorshëm.