Latauksen lukeminen paloina ei vaadi chunked HTTP:tä
Erota sovelluksen rajatut luvut HTTP/1.1-viestikehyksestä, kun lataus käyttäytyy eri tavalla edelleenvälittävän välityspalvelimen kautta.
Ei. Asiakas voi lukea suuren tiedoston pieninä puskureina ja lähettää sen tunnetulla Content-Lengthillä. Rajatut luvut hallitsevat muistinkäyttöä; HTTP-kehys kertoo vastaanottajalle, mihin pyynnön runko päättyy.
Vakaa tiedosto, jonka tavupituuden HTTP-kirjasto tuntee, eroaa generaattorista, joka tuottaa tuntemattoman määrän dataa. Käytä kirjaston tukemaa runkorajapintaa kummallekin lähteelle. Koko tiedostoa ei tarvitse koota merkkijonoon vain pituuden antamiseksi.
HTTP/1.1:n osalta tutki todella lähetetty kehys: Content-Length tai chunked-siirtokoodaus protokollan sääntöjen mukaan. Chunked-koodaus lisää kokomerkinnät tiedoston sisällön ulkopuolelle. Älä yhdistä ristiriitaisia kehyskenttiä äläkä arvaa pituutta saadaksesi välityspalvelimen hyväksymään latauksen.
Jos välityspalvelimen kautta kulkeva lataus epäonnistuu, kirjaa HTTP-versio, rungon lähde ja ensimmäinen hylkäys. 411-vastaus viittaa erilaiseen tutkintaan kuin yhteyden sulkeutuminen kesken rungon. Jos sen sijaan todennuksen uudelleenyritykset epäonnistuvat, tarkista, voidaanko latauksen runko toistaa. Sovelluksen lukupuskurin koon muuttaminen voi jättää pyynnön kehyksen täsmälleen ennalleen.
Reitti on tärkeä tuolle havainnolle. Selkokielinen välitys paljastaa latauksen HTTP-kehyksen välityspalvelimelle; tavallinen päästä päähän -HTTPS sijoittaa sen tunneliin. HTTP/2 käyttää omaa kehystään. Siksi Squidin historialliset rajoitukset selittävät tiettyjä vanhoja epäonnistumisia, eivät sääntöä, jonka mukaan jokainen nykyinen välityspalvelin hylkää striimatut lataukset.