A feltöltés darabokban olvasása nem igényel chunked HTTP-t

Nem. Az ügyfél olvashat egy nagy fájlt kis pufferekben, és ismert Content-Length-del küldheti el. A korlátos olvasások szabályozzák a memóriahasználatot; a HTTP keretek közlik a fogadóval, hol végződik a kérés törzse.

Egy stabil fájl, amelynek bájthosszát a HTTP könyvtár ismeri, különbözik egy generátortól, amely ismeretlen mennyiségű adatot állít elő. Mindkét forráshoz a könyvtár által támogatott törzs-interfészt használja. Nem kell a teljes fájlt egyetlen karakterlánccá összeállítani csak azért, hogy hosszt adjon.

HTTP/1.1 esetén vizsgálja meg a ténylegesen elküldött keretezést: Content-Length vagy chunked átviteli kódolás a protokoll szabályai szerint. A chunked kódolás méretjelölőket ad a fájl tartalmán kívül. Ne kombináljon ellentmondó keretezési mezőket, és ne találjon ki hosszt, hogy rábírjon egy proxyt a feltöltés elfogadására.

Ha a proxyn átmenő feltöltés meghiúsul, jegyezze fel a HTTP-verziót, a törzs forrását és az első elutasítást. A 411 válasz más vizsgálatra utal, mint a törzs közepén bezáruló kapcsolat. Ha inkább a hitelesítési újrapróbálkozások hiúsulnak meg, ellenőrizze, visszajátszható-e a feltöltés törzse. Az alkalmazás olvasási pufferméretének módosítása pontosan úgy hagyhatja a kérés keretezését, ahogy volt.

Az útvonal számít ehhez a megfigyeléshez. A nyílt szövegű továbbítás feltárja a feltöltés HTTP-keretezését a proxy előtt; a szokásos végponttól végpontig tartó HTTPS alagútba helyezi. A HTTP/2 a saját keretezését használja. A Squid történelmi korlátai ezért bizonyos régi hibákat magyaráznak, nem pedig azt a szabályt, hogy minden mai proxy elutasítja a streamelt feltöltéseket.