Legi la alŝuton en blokoj ne postulas chunked HTTP
Apartigu limigitajn aplikaĵajn legadojn de la HTTP/1.1-mesaĝa kadrigo kiam alŝuto kondutas alie tra antaŭa prokuro.
Ne. Kliento povas legi grandan dosieron en malgrandaj bufroj kaj sendi ĝin kun konata Content-Length. Limigitaj legadoj regas la memorkonsumon; la HTTP-kadrigo diras al la ricevanto kie finiĝas la korpo de la peto.
Stabila dosiero, kies bajtan longon konas la HTTP-biblioteko, diferencas de generatoro kiu produktas nekonatan kvanton da datumoj. Uzu la korpo-interfacon subtenatan de la biblioteko por ambaŭ fontoj. Vi ne bezonas kunmeti la tutan dosieron en ĉenon nur por doni longon.
Ĉe HTTP/1.1, inspektu la efektive senditan kadrigon: Content-Length aŭ chunked transporta kodigo laŭ la reguloj de la protokolo. Chunked-kodigo aldonas grandmarkilojn ekster la dosiera enhavo. Ne kunmetu kontraŭdirajn kadrajn kampojn kaj ne divenu longon por persvadi prokuron akcepti la alŝuton.
Se alŝuto tra prokuro malsukcesas, notu la HTTP-version, la korpan fonton kaj la unuan rifuzon. Respondo 411 sugestas alian esploron ol konekto kiu fermiĝas meze de korpo. Se anstataŭe malsukcesas aŭtentigaj reprovoj, kontrolu ĉu la alŝuta korpo povas esti reludata. Ŝanĝi la legobufran grandecon de la aplikaĵo povas lasi la petan kadrigon precize kiel ĝi estis.
La vojo gravas por tiu observo. Klarteksta plusendado elmetas la HTTP-kadrigon de la alŝuto al la prokuro; ordinara end-to-end HTTPS metas ĝin en tunelon. HTTP/2 uzas sian propran kadrigon. Historiaj limigoj de Squid do klarigas koncernajn malnovajn malsukcesojn, ne regulon ke ĉiu nuna prokuro rifuzas streamajn alŝutojn.