Վերբեռնումը մասերով կարդալը chunked HTTP չի պահանջում
Առանձնացրե՛ք հավելվածի սահմանափակ ընթերցումները HTTP/1.1 հաղորդագրության շրջանակավորումից, երբ վերբեռնումը փոխանցվող պրոքսի միջով այլ կերպ է վարվում։
Ոչ։ Հաճախորդը կարող է մեծ ֆայլը կարդալ փոքր բուֆերներում և ուղարկել այն հայտնի Content-Length-ով։ Սահմանափակ ընթերցումները կառավարում են հիշողության օգտագործումը. HTTP շրջանակավորումը ստացողին ասում է, թե որտեղ է ավարտվում հարցման մարմինը։
Կայուն ֆայլը, որի բայթային երկարությունը HTTP գրադարանը գիտի, տարբերվում է անհայտ ծավալի տվյալներ արտադրող գեներատորից։ Երկու աղբյուրների համար էլ օգտագործե՛ք գրադարանի աջակցած մարմնի ինտերֆեյսը։ Պետք չէ ամբողջ ֆայլը հավաքել մեկ տողում միայն երկարություն տալու համար։
HTTP/1.1-ի համար ստուգե՛ք փաստացի ուղարկված շրջանակավորումը՝ Content-Length կամ chunked փոխանցման կոդավորում՝ ըստ արձանագրության կանոնների։ Chunked կոդավորումը ֆայլի բովանդակությունից դուրս ավելացնում է չափի նշիչներ։ Մի՛ համադրեք հակասական շրջանակավորման դաշտեր և մի՛ գուշակեք երկարություն՝ պրոքսիին վերբեռնումն ընդունելու համոզելու համար։
Եթե պրոքսիով վերբեռնումը ձախողվի, գրանցե՛ք HTTP տարբերակը, մարմնի աղբյուրը և առաջին մերժումը։ 411 պատասխանը հուշում է այլ քննություն, քան մարմնի կեսին փակվող կապը։ Եթե փոխարենը ձախողվում են նույնականացման կրկնափորձերը, ստուգե՛ք՝ կարելի է արդյոք վերբեռնման մարմինը նորից նվագարկել։ Հավելվածի ընթերցման բուֆերի չափը փոխելը կարող է հարցման շրջանակավորումը թողնել ճիշտ այնպիսին, ինչպիսին եղել է։
Ուղին կարևոր է այդ դիտարկման համար։ Բաց տեքստով փոխանցումը վերբեռնման HTTP շրջանակավորումը բացահայտում է պրոքսիի առջև. սովորական ծայրից ծայր HTTPS-ը այն դնում է թունելի մեջ։ HTTP/2-ը օգտագործում է իր սեփական շրջանակավորումը։ Ուստի Squid-ի պատմական սահմանափակումները բացատրում են որոշակի հին ձախողումներ, ոչ թե կանոն, որ յուրաքանչյուր ներկա պրոքսի մերժում է հոսքային վերբեռնումները։