Kad lejupielādētā datne sākas ar HTTP statusa rindu

Ja it kā PDF vai izklājlapa sākas ar HTTP/1.1 200 OK, lejupielādētājs saglabāja neapstrādātu atbildi, nevis datni. Šajā shematiskajā atbildē ir tikai četri satura baiti:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

Datne ir DATA. Statusa rinda, galvenes, izmēra marķieris un noslēguma struktūra pieder HTTP. Noņemt noteiktu baitu skaitu nav droši, jo galveņu garumi atšķiras. Kopējot visu pēc pirmās tukšās rindas, joprojām paliek gabalu ietvars, un informatīvās atbildes var būt pirms galīgās atbildes.

Parastai lejupielādei aizstājiet kopēšanu no neapstrādātas ligzdas uz datni ar HTTP klienta atbildes pamatteksta saskarni. Konfigurējiet tā starpniekserveri, pārbaudiet galīgo statusu un straumējiet pamattekstu uz pagaidu izvadi. Klients apstrādā ziņojuma ietvaru: ar garumu norobežoti, gabalos (chunked) un ar savienojumu norobežoti pamatteksti prasa atšķirīgu parsēšanu.

Satura kodējums ir vēl viens slānis. Izlemiet, vai jums vajag atkodētus datnes baitus vai skaidri pieprasītu neapstrādātu saturu, balstoties uz klienta dokumentēto uzvedību. Saspiesti baiti nav automātiski starpniekservera bojājums.

Ja lietotnei jāsaglabā ligzdas līmeņa kods, tai pašai jāatbild par visiem šiem parsēšanas noteikumiem, kā arī lasīšanas un rakstīšanas apstrādi. Rakstiet tikai to baitu skaitu, ko lasīšana faktiski atgriezusi, nevis bufera ietilpību, un apstrādājiet daļēju rakstīšanu. Citādi novecojis bufera saturs var sabojāt pat pareizi izgūtu pamattekstu.

HTTPS prasa vairāk nekā CONNECT atbildes noņemšanu: pēc veiksmīgas tuneļa izveides jāizveido galamērķa TLS un pēc tam jāparsē iekšējā HTTP atbilde. Šifrētie baiti pēc starpniekservera galvenēm nav lejupielādējamā datne.

Neizdevušos vai nepilnīgu izvadi atstājiet pagaidu nosaukumā. Publicējiet to tikai pēc tam, kad pārsūtīšana un datnes pārbaudes ir veiksmīgas; ne tukša datne nepierāda pilnīgu lejupielādi.