Чытанне запампоўкі кавалкамі не патрабуе chunked HTTP
Аддзяляйце абмежаваныя чытанні праграмы ад фарміравання паведамленняў HTTP/1.1, калі запампоўка паводзіць сябе інакш праз прамы проксі.
Не. Кліент можа чытаць вялікі файл у невялікіх буферах і адпраўляць яго з вядомым Content-Length. Абмежаваныя чытанні кіруюць выкарыстаннем памяці; фарміраванне HTTP паведамляе атрымальніку, дзе заканчваецца цела запыту.
Стабільны файл, даўжыню якога ў байтах ведае бібліятэка HTTP, адрозніваецца ад генератара, які выдае невядомую колькасць даных. Для абодвух крыніц выкарыстоўвайце падтрымоўваны бібліятэкай інтэрфейс цела. Не трэба збіраць увесь файл у радок толькі дзеля таго, каб падаць даўжыню.
Для HTTP/1.1 праверце фактычна адпраўленае фарміраванне: Content-Length або chunked transfer coding паводле правілаў пратакола. Chunked-кадаванне дадае маркеры памеру па-за змесцівам файла. Не спалучайце супярэчлівыя поля фарміравання і не ўгадвайце даўжыню, каб схіліць проксі прыняць запампоўку.
Калі запампоўка праз проксі не ўдалася, запішыце версію HTTP, крыніцу цела і першую адмову. Адказ 411 патрабуе іншага расследавання, чым злучэнне, якое закрываецца на сярэдзіне цела. Калі замест гэтага не ўдаюцца паўторныя спробы аўтэнтыфікацыі, праверце ці можна паўторна прайграць цела запампоўкі. Змена памеру буфера чытання праграмы можа пакінуць фарміраванне запыту такім жа, як было.
Маршрут важны для гэтага назірання. Перадача адкрытым тэкстам паказвае проксі фарміраванне HTTP запампоўкі; звычайны HTTPS ад канца да канца трымае яго ў тунелі. HTTP/2 выкарыстоўвае ўласнае фарміраванне. Таму гістарычныя абмежаванні Squid тлумачаць пэўныя старыя збоі, а не правіла, што кожны сучасны проксі адхіляе патокавыя запампоўкі.