Kiam la elŝutita dosiero komenciĝas per HTTP-statusa linio

Se supozata PDF aŭ kalkultabelo komenciĝas per HTTP/1.1 200 OK, la elŝutilo konservis krudan respondon anstataŭ la dosieron. Ĉi tiu skema respondo enhavas nur kvar bajtojn da enhavo:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

La dosiero estas DATA. La statusa linio, kaplinioj, grandmarkilo kaj fina strukturo apartenas al HTTP. Forigi fiksan nombron da bajtoj estas nesekure ĉar kaplinioj varias laŭ longo. Kopii ĉion post la unua malplena linio ankoraŭ lasas pecan kadrigon, kaj informaj respondoj povas antaŭi la finan respondon.

Por normala elŝuto, anstataŭigu la kopiadon de kruda ingo al dosiero per la interfaco de respondkorpo de la HTTP-kliento. Agordu ĝian prokurilon, validigu la finan statuson kaj fluigu la korpon al provizora eligo. La kliento prizorgas la mesaĝan kadrigon: korpoj limigitaj per longo, per pecoj kaj per konekto postulas malsamajn analizojn.

Enhava kodigo estas plua tavolo. Decidu, ĉu vi bezonas malkoditajn dosierbajtojn aŭ eksplicite petitajn krudan enhavon, laŭ la dokumentita konduto de la kliento. Kunpremitaj bajtoj ne estas aŭtomate prokura difekto.

Se la aplikaĵo devas konservi kodon je inga nivelo, ĝi posedas ĉiujn tiujn analizajn regulojn kaj ankaŭ la legadon kaj skribadon. Skribu nur la nombron da bajtoj efektive redonitaj de legado, ne la kapaciton de la bufro, kaj traktu partajn skribojn. Alie malnova bufra enhavo povas difekti eĉ ĝuste eltiritan korpon.

HTTPS postulas pli ol senŝeligi CONNECT-respondon: post sukcesa tunela starigo, starigu destinadan TLS kaj poste analizu la internan HTTP-respondon. La ĉifritaj bajtoj post la kaplinioj de la prokurilo ne estas la elŝutebla dosiero.

Lasu malsukcesan aŭ nekompletan eligon sub provizora nomo. Publikigu ĝin nur post kiam la transigo kaj la dosierkontroloj sukcesos; ne-malplena dosiero ne pruvas kompletan elŝuton.