Hapana. Mteja anaweza kusoma faili kubwa katika buffers ndogo na kupeleka kwa Content-Length inayojulikana. Usomaji wenye mipaka hudhibiti matumizi ya kumbukumbu; uandishi wa HTTP humweleza mpokeaji mahali mwili wa ombi unaishia.

Faili thabiti ambayo maktaba ya HTTP inajua urefu wake kwa baiti ni tofauti na kizalishaji kinachozalisha kiasi kisichojulikana cha data. Tumia kiolesura cha mwili kinachotumika katika maktaba kwa chanzo chochote kati ya hivi. Huhitaji kuunganisha faili yote kuwa string ili tu kutoa urefu.

Kwa HTTP/1.1, chunguza uandishi uliotumwa kweli: Content-Length au chunked transfer coding kulingana na kanuni za itifaki. Uandishi wa chunked huongeza alama za ukubwa nje ya maudhui ya faili. Usichanganye sehemu za uandishi zinazopingana na usikisie urefu ili kumshawishi proxy ikubali upakiaji.

Ikiwa upakiaji kupitia proxy unashindwa, rekodi toleo la HTTP, chanzo cha mwili na kukataliwa kwa kwanza. Jibu la 411 linadokeza uchunguzi tofauti na muunganisho unaofungwa katikati ya mwili. Ikiwa majaribio ya uthibitisho yanashindwa badala yake, angalia ikiwa mwili wa upakiaji unaweza kurudishwa. Kubadilisha ukubwa wa buffer ya usomaji ya programu kunaweza kuacha uandishi wa ombi kama ulivyokuwa.

Njia ni muhimu kwa uchunguzi huo. Upelekaji wa maandishi wazi hufichua uandishi wa HTTP wa upakiaji kwa proxy; HTTPS ya kawaida kutoka mwanzo hadi mwisho huiweka ndani ya handaki. HTTP/2 hutumia uandishi wake mwenyewe. Kwa hiyo mapungufu ya kihistoria ya Squid yanaeleza kushindwa fulani za zamani, sio kanuni kwamba kila proxy ya sasa inakataa upakiaji unaotiririshwa.

Makala zinazohusiana