ፋይሉን በቁርጥራጭ ማንበብ chunked HTTP አይጠይቅም

አይደለም። Client ትልቅ ፋይልን በትንሽ buffer ማንበብና በሚታወቅ Content-Length መላክ ይችላል። የተወሰነ ንባብ የማስታወሻ አጠቃቀምን ይቆጣጠራል፤ HTTP framing ደግሞ ተቀባዩ የጥያቄው body የሚያበቃበትን ቦታ ይነግረዋል።

የHTTP ላይብራሪ የbyte ርዝመቱን የሚያውቀው የተረጋጋ ፋይል ከማይታወቅ መጠን ዳታ ከሚያመነጨ generator ይለያል። ለሁለቱም ምንጮች ላይብራሪው የሚደግፈውን body interface ይጠቀሙ። ርዝመት ለመስጠት ብቻ ፋይሉን በሙሉ ወደ string መሰብሰብ አያስፈልግም።

ለHTTP/1.1 በትክክል የተላከውን framing ይመርምሩ፦ በፕሮቶኮሉ ህጎች መሰረት Content-Length ወይም chunked transfer coding። Chunked coding ከፋይሉ ይዘት ውጭ የመጠን ምልክቶችን ይጨምራል። እርስ በርስ የሚጋጩ የframing መስኮችን አያዋህዱ ወይም proxy ጭነቱን እንዲቀበል ርዝመት አይገምቱ።

በproxy የሚያልፍ ጭነት ካልተሳካ፣ የHTTP ስሪት፣ የbody ምንጭ እና የመጀመሪያውን ውድቅ ይመዝግቡ። የ411 ምላሽ ከbody መሃል ላይ ከሚዘጋ ግንኙነት የተለየ ምርመራ ይጠቁማል። በምትኩ የማረጋገጫ ድጋሚ ሙከራዎች ካልተሳኩ፣ የጭነቱ body እንደገና መጫወት እንደሚችል ይመልከቱ። የመተግበሪያውን የread-buffer መጠን መቀየር የጥያቄውን framing እንዳለ ሊያስቀር ይችላል።

መንገዱ ለዚያ ምልከታ ይጠቅማል። ግልጽ ጽሑፍ ማስተላለፍ የጭነቱን HTTP framing ለproxy ያጋልጣል፤ የተለመደ end-to-end HTTPS ግን በtunnel ውስጥ ያስቀምጠዋል። HTTP/2 የራሱን framing ይጠቀማል። ስለዚህ የቀድሞ የSquid ገደቦች የተወሰኑ የድሮ ውድቀቶችን ያብራራሉ፣ አሁን ያለው proxy ሁሉ streamed ጭነትን ውድቅ ያደርጋል የሚል ህግ አይደለም።