Читањето на поставувањето на делови не бара chunked HTTP
Одвојте ги ограничените читања на апликацијата од рамкирањето на пораките HTTP/1.1 кога поставувањето се однесува поинаку преку напреден прокси.
Не. Клиентот може да чита голема датотека во мали бафери и да ја испрати со познат Content-Length. Ограничените читања го контролираат користењето меморија; рамкирањето на HTTP му кажува на примачот каде завршува телото на барањето.
Стабилна датотека чија бајтна должина ја знае HTTP библиотеката се разликува од генератор што произведува непозната количина податоци. За двата извора користете го поддржаното интерфејс за тело на библиотеката. Не треба да ја составувате целата датотека во низа само за да дадете должина.
За HTTP/1.1, проверете го навистина испратеното рамкирање: Content-Length или chunked преносно кодирање според правилата на протоколот. Chunked кодирањето додава ознаки за големина надвор од содржината на датотеката. Не комбинирајте противречни полиња за рамкирање и не погодувајте должина за да убедите прокси да го прифати поставувањето.
Ако поставувањето преку прокси не успее, запишете ја верзијата на HTTP, изворот на телото и првото одбивање. Одговорот 411 упатува на поинаква истрага од врска што се затвора на средината на телото. Ако наместо тоа не успеат обидите за повторна автентикација, проверете дали телото на поставувањето може повторно да се пушти. Менувањето на големината на баферот за читање на апликацијата може да го остави рамкирањето на барањето точно како што било.
Патеката е важна за тоа набљудување. Преносот со отворен текст го изложува HTTP рамкирањето на поставувањето пред проксито; обичниот HTTPS од крај до крај го става во тунел. HTTP/2 го користи сопственото рамкирање. Затоа историските ограничувања на Squid објаснуваат одредени стари неуспеси, а не правило дека секој сегашен прокси одбива стриминг поставувања.