En hypotetisk report.xlsx er 8 KB og åbner som en login-side. Programmet gemte en fil med succes, men fik aldrig det tilsigtede regneark. Et filnavn vælges lokalt; det er ikke bevis på, hvad der ankom.

Gør accept til et særskilt trin, før den midlertidige download offentliggøres:

  1. Kræv en vellykket overførsel og den forventede svartilstand. Bevar en fejl i stedet for at behandle de bytes, der blev skrevet før den, som komplette.
  2. Sammenlign indholdet med den forventede filtype. En login- eller filterside kan returnere 200. Content-Type kan være forkert, og et HTML-præfiks i et regneark er en advarsel, der kræver undersøgelse. En fil, der begynder med en HTTP-statuslinje, peger i stedet på rå svardata.
  3. Validér de komplette gemte bytes mod en betroet kontrolsum eller signatur, når en sådan findes. Først efter at de krævede kontroller er bestået, bør applikationen offentliggøre eller bruge den endelige fil.

At beregne en hash uden en forventet værdi identificerer kun de bytes, du modtog. En usigneret kontrolsum hentet ad samme utroværdige vej kan dele filens svaghed; brug en uafhængig betroet forventning.

Vær også opmærksom ved størrelsessammenligninger. En HTTP-klient kan afkode indholdskodning under læsningen, så den resulterende fillængde kan med rette afvige fra en header, der beskriver den kodede meddelelse. Sammenlign udgiverens forventning med den repræsentation, der faktisk blev gemt.

Hvis et forsøg mislykkes, skal du kun beholde det midlertidige output til en bevidst genoptagelse eller kassere det. Ufuldstændige bytes på den endelige sti tvinger det næste program til at gætte, om de kan bruges.

Relaterede artikler